home *** CD-ROM | disk | FTP | other *** search
/ Celestin Apprentice 2 / Apprentice-Release2.iso / Information / Digests / CSMP Digest / volume 3 / csmp-digest-v3-057 / doubleCR.1 < prev   
Encoding:
Text File  |  1994-12-08  |  287.8 KB  |  7,012 lines

  1. C.S.M.P. Digest             Tue, 13 Sep 94       Volume 3 : Issue 57
  2.  
  3. Today's Topics:
  4.  
  5.         Best Sprite Package?
  6.         CW PASCAL vs THINK PASCAL
  7.         Items in system menu bar
  8.         Text searches.
  9.         Ticks (was: Clover+. interrupt?)
  10.         What is the point of MPW?
  11.         Where have the standards gone? [a high level question]
  12.  
  13.  
  14.  
  15. The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
  16. (pottier@clipper.ens.fr).
  17.  
  18. The digest is a collection of article threads from the internet newsgroup
  19. comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
  20. regularly and want an archive of the discussions.  If you don't know what a
  21. newsgroup is, you probably don't have access to it.  Ask your systems
  22. administrator(s) for details.  If you don't have access to news, you may
  23. still be able to post messages to the group by using a mail server like
  24. anon.penet.fi (mail help@anon.penet.fi for more information).
  25.  
  26. Each issue of the digest contains one or more sets of articles (called
  27. threads), with each set corresponding to a 'discussion' of a particular
  28. subject.  The articles are not edited; all articles included in this digest
  29. are in their original posted form (as received by our news server at
  30. nef.ens.fr).  Article threads are not added to the digest until the last
  31. article added to the thread is at least two weeks old (this is to ensure that
  32. the thread is dead before adding it to the digest).  Article threads that
  33. consist of only one message are generally not included in the digest.
  34.  
  35. The digest is officially distributed by two means, by email and ftp.
  36.  
  37. If you want to receive the digest by mail, send email to listserv@ens.fr
  38. with no subject and one of the following commands as body:
  39.     help                        Sends you a summary of commands
  40.     subscribe csmp-digest Your Name    Adds you to the mailing list
  41.     signoff csmp-digest            Removes you from the list
  42. Once you have subscribed, you will automatically receive each new
  43. issue as it is created.
  44.  
  45. The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
  46. Questions related to the ftp site should be directed to
  47. scott.silver@dartmouth.edu. Currently no previous volumes of the CSMP
  48. digest are available there.
  49.  
  50. Also, the digests are available to WAIS users.  To search back issues
  51. with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use
  52. http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html.
  53.  
  54.  
  55. -------------------------------------------------------
  56.  
  57. >From gkm@jolt.mpx.com.au (Gavin K Maxwell)
  58. Subject: Best Sprite Package?
  59. Date: 19 Aug 1994 06:15:19 GMT
  60. Organization: Microplex Pty Ltd
  61.  
  62. I would like to know peoples impressions of the available sprite 
  63. animation libraries.  The two I'm aware of are SpriteWorld and Sprite 
  64. Animation Toolkit (SAT), are there any others?  Which is the best?  
  65. Are there any gotchas to watch out for?  What are their limitations?
  66.  
  67. Any help would be appreciated,
  68. --
  69. Gavin,
  70. +---------------------+-----------------------------+      |||||||
  71. | Gavin Maxwell,      | "You can't have everything. |      | _ _ |
  72. | gkm@jolt.mpx.com.au |  Where would you put it!!"  |      | O O | 
  73. | +61-2-3426236       |                             |      |  ^  |
  74. +---------------------+-----------------------------+       \ ~ /
  75.                                                              ---
  76.  
  77. +++++++++++++++++++++++++++
  78.  
  79. >From mab22@po.cwru.edu (Mike Balfour)
  80. Date: 19 Aug 1994 14:47:14 GMT
  81. Organization: Overload Engineering
  82.  
  83. In article <331iln$4fq@inferno.mpx.com.au>, gkm@jolt.mpx.com.au (Gavin K
  84. Maxwell) wrote:
  85.  
  86. > I would like to know peoples impressions of the available sprite 
  87. > animation libraries.  The two I'm aware of are SpriteWorld and Sprite 
  88. > Animation Toolkit (SAT), are there any others?  Which is the best?  
  89. > Are there any gotchas to watch out for?  What are their limitations?
  90.  
  91. Well, it seems that more people out there are using SpriteWorld, just
  92. because it was released about a month before SAT.  SpriteWorld is also more
  93. geared to C, where SAT was originally written for Pascal and has since been
  94. updated to be usable from C.  Between the two, I'm very biased toward SAT. 
  95. I beta-tested it for several months, and I found it was very easy to learn,
  96. easy to use, and just good quick code.  It even makes my bad code run fast
  97. (who else can claim that?)!  Somebody else recently posted the concern that
  98. SAT still has warnings in it from the author, Ingemar, about various
  99. kluges.  I wouldn't be concerned - everything's actually amazingly stable. 
  100. I should know, I tried some pretty strange things from time to time to try
  101. to make it break...
  102.  
  103. MB
  104. --
  105. - --------------------------------+--------------------------------
  106. Mike Balfour, Partner             | BS/MS Candidate - ECMP
  107. Overload Engineering              | Case Western Reserve University
  108. "New Ideas for a Brighter Future" | Cleveland, OH
  109.  
  110. +++++++++++++++++++++++++++
  111.  
  112. >From al@crucible.powertools.com (Al Evans)
  113. Date: 19 Aug 94 14:57:16 GMT
  114. Organization: PowerTools, Austin, Texas
  115.  
  116. In article <331iln$4fq@inferno.mpx.com.au> gkm@jolt.mpx.com.au (Gavin K Maxwell) writes:
  117.  
  118. >I would like to know peoples impressions of the available sprite 
  119. >animation libraries.  The two I'm aware of are SpriteWorld and Sprite 
  120. >Animation Toolkit (SAT), are there any others?  Which is the best?  
  121. >Are there any gotchas to watch out for?  What are their limitations?
  122.  
  123. You might want to have a look at Graphic Elements. To my way of thinking,
  124. it offers a lot more flexibility than either SpriteWorld or SAT -- but
  125. then, I'm the author:-)
  126.  
  127. As to which is best for you, that probably depends on what you want
  128. to do. Graphic Elements has lots of built-in features: buttons and
  129. sliders, horizontal and vertical mirroring, special effects. SpriteWorld
  130. has good performance with free licensing and complete source code. SAT
  131. has both C and Pascal interfaces and offers excellent support for older
  132. systems. Both Graphic Elements and SpriteWorld offer native PPC support;
  133. I'm not sure about SAT.
  134.                     --Al Evans--
  135. -- 
  136. Al Evans        |   Graphic Elements: A new standard for 
  137. ________________________|__ high-performance interactive Macintosh graphics.
  138. al@crucible.powertools.com |  Available from mac.archive.umich.edu
  139. - -------------------------| /mac/development/libraries/graphicelements2.sit.hqx
  140.  
  141. +++++++++++++++++++++++++++
  142.  
  143. >From ez033265@ucdavis.edu (Will Iverson)
  144. Date: Fri, 19 Aug 1994 18:01:34 GMT
  145. Organization: University of California, Davis
  146.  
  147. In article <479@crucible.powertools.com>, al@crucible.powertools.com (Al
  148. Evans) wrote:
  149.  
  150. > In article <331iln$4fq@inferno.mpx.com.au> gkm@jolt.mpx.com.au (Gavin K
  151. Maxwell) writes:
  152. > As to which is best for you, that probably depends on what you want
  153. > to do. Graphic Elements has lots of built-in features: buttons and
  154. > sliders, horizontal and vertical mirroring, special effects. SpriteWorld
  155. > has good performance with free licensing and complete source code. SAT
  156. > has both C and Pascal interfaces and offers excellent support for older
  157. > systems. Both Graphic Elements and SpriteWorld offer native PPC support;
  158. > I'm not sure about SAT.
  159.  
  160. SAT (as of version 2.1.2) doesn't offer native PPC support.
  161.  
  162. -Will Iverson
  163.  
  164. +++++++++++++++++++++++++++
  165.  
  166. >From we37026@vub.ac.be (DICTUS ROY)
  167. Date: 20 Aug 1994 21:50:45 GMT
  168. Organization: Brussels Free Universities (VUB/ULB), Belgium
  169.  
  170. I've looked at all three packages a while ago; SAT, SpriteWorld and
  171. Graphics Elements.
  172.  
  173. I've written a few games using SAT and was most impressed with it.  Good
  174. interface, logical structure, fast and reliable code.
  175.  
  176. SpriteWorld looks good too, but seems much harder to use than SAT.
  177.  
  178. Graphics Elements, to be frank, I wasn't very impressed with (no offense
  179. to the author).  I liked SAT and SW better.
  180.  
  181. I'll stick to SAT.  I just like it the best and it has proven itself.
  182.  
  183. Games on the Net that were written with SAT:
  184. - Asterax
  185. - Bachman 2
  186. - CyberNation
  187. - Missions of the Reliant
  188. - Warbirds
  189. - ...
  190.  
  191. How many games have been written with SpriteWorld?  I don't recall ever
  192. having seen any reference to it in any game...
  193.  
  194. Just my $0.02,
  195.  
  196. - Roy
  197.  
  198. +++++++++++++++++++++++++++
  199.  
  200. >From hamptn@uow.edu.au ( Dan Hampton )
  201. Date: 25 Aug 1994 12:00:10 +1000
  202. Organization: University of Wollongong, NSW, Australia.
  203.  
  204. we37026@vub.ac.be (DICTUS ROY) writes:
  205.  
  206. >I've looked at all three packages a while ago; SAT, SpriteWorld and
  207. >Graphics Elements.
  208.  
  209. >I've written a few games using SAT and was most impressed with it.  Good
  210. >interface, logical structure, fast and reliable code.
  211.  
  212. >SpriteWorld looks good too, but seems much harder to use than SAT.
  213.  
  214. >Graphics Elements, to be frank, I wasn't very impressed with (no offense
  215. >to the author).  I liked SAT and SW better.
  216.  
  217. >I'll stick to SAT.  I just like it the best and it has pr
  218. >Games on the Net that were written with SAT:
  219. >- Asterax
  220. >- Bachman 2
  221. >- CyberNation
  222. >- Missions of the Reliant
  223. >- Warbirds
  224. >- ...
  225.  
  226. >How many games have been written with SpriteWorld?  I don't recall ever
  227. >having seen any reference to it in any game...
  228.  
  229. Yeah that is true, It'd be interesting to see if anything decent has been
  230. made with SpriteWorld. The latest version is very complete
  231. and packed with features, PPC native, and extremely fast.
  232.  
  233. There can be a bit of fiddling around with things that you'd
  234. rather not have to deal with thou.
  235.  
  236. Where can Graphic Elements be gotten from anyway? (ftp site {which one})
  237.  
  238.  
  239. - --------------------------------------------------------------------
  240. It is an important and popular fact that things are not always what
  241. they seem.  For instance, on the planet Earth, man had always assumed
  242. that he was more intelligent than dolphins because he had achieved so
  243. much -- the wheel, New York, wars and so on -- whilst all the dolphins
  244. had ever done was muck about in the water having a good time.  But
  245. conversely, the dolphins had always believed that they were far more
  246. intelligent than man -- for precisely the same reasons.
  247.              -- Douglas Adams "The Hitch-Hikers' Guide To The Galaxy".
  248. - --------------------------------------------------------------------
  249. Dan Hampton -- Austinmer, NSW, Australia.          <hamptn@uow.edu.au>
  250. - --------------------------------------------------------------------
  251.  
  252. +++++++++++++++++++++++++++
  253.  
  254. >From al@crucible.powertools.com (Al Evans)
  255. Date: 25 Aug 94 14:29:13 GMT
  256. Organization: PowerTools, Austin, Texas
  257.  
  258. In article <33gtva$gs7@wumpus.cc.uow.edu.au> hamptn@uow.edu.au ( Dan Hampton ) writes:
  259.  
  260. >Yeah that is true, It'd be interesting to see if anything decent has been
  261. >made with SpriteWorld. The latest version is very complete
  262. >and packed with features, PPC native, and extremely fast.
  263.  
  264. I have recently done some (contract) finishing work on a piece of
  265. educational software from a major educational publishing company that
  266. used SpriteWorld for its animation.
  267.  
  268. >There can be a bit of fiddling around with things that you'd
  269. >rather not have to deal with thou.
  270.  
  271. Although I did not deal directly with the animation routines in this
  272. package, it seemed to me that they required an enormous number of
  273. lines of code for what they did.
  274.  
  275. >Where can Graphic Elements be gotten from anyway? (ftp site {which one})
  276.  
  277. See my .signature.
  278.                     --Al Evans--
  279. -- 
  280. Al Evans        |   Graphic Elements: A new standard for 
  281. ________________________|__ high-performance interactive Macintosh graphics.
  282. al@crucible.powertools.com |  Available from mac.archive.umich.edu
  283. - -------------------------| /mac/development/libraries/graphicelements2.sit.hqx
  284.  
  285. +++++++++++++++++++++++++++
  286.  
  287. >From ingemar@lysator.liu.se (Ingemar Ragnemalm)
  288. Date: 28 Aug 1994 10:28:19 GMT
  289. Organization: (none)
  290.  
  291. ez033265@ucdavis.edu (Will Iverson) writes:
  292.  
  293. >SAT (as of version 2.1.2) doesn't offer native PPC support.
  294.  
  295. This is true, and the reason is that CodeWarrior is so damn buggy! I've tried
  296. porting some smaller hacks to it, and I'm getting tired of rebooting over
  297. and over again, with the debugger not catching any problems at all.
  298.  
  299. Actually, if there is some SKILLED programmer out there, with some
  300. experience with CodeWarrior Pascal, I'd be happy to let him/her try porting
  301. it. Perhaps a CodeWarrior version could skip the 68000 support and all
  302. blitters except 8-bit, just to get it running for PPC?
  303.  
  304. Considering what package is BEST, I think it's a matter of needs and taste.
  305.  
  306. SW is written as an Apple Manager. Fairly general, not too quick to get
  307. started with, handles sprite management only. I found it a little worrying
  308. to find out that it's made by a programmer who hasn't made a computer game
  309. in his life (that we know of). I mean, if HE can't make games with it,
  310. why should I believe I can? (The big problem I'm aiming at is the lack of
  311. a full game demo.) I'm not sure it has more USERS than SAT. More
  312. people have it, and I'm sure lots of people grab code from it, but who
  313. knows how many people uses it? It has some strong points, like staggered
  314. drawing (which isn't impossible in SAT, but a bit harder) and grouping
  315. the sprites in distinct so-called layers.
  316.  
  317. SAT is written for kick-start coding, for getting up in the air quickly,
  318. with a very small set of calls for the beginner. It includes asynch sound,
  319. simply because 99.9% of the programmers will need that too, and you don't
  320. want all the hassle making it work with Sound Manager 2! Good support for
  321. Pascal as well as C is a must. Pascal is easier to work with, and SAT is
  322. made to be beginner-friendly. NONE of the others support Pascal to any
  323. extent that is worth mentioning. SAT clearly has the best support for
  324. Macs not supporting 8-bit color (i.e. old Macs and Powerbooks), and supports
  325. scrolling games.
  326.  
  327. Graphical Elements, I've hardly had time to look at that at all, but I got the
  328. impression of a slightly different scope, not only at games. (I'll leave
  329. it to Al to make more specific statements.)
  330.  
  331. --
  332. - -
  333. Ingemar Ragnemalm, PhD
  334. Image processing, Mac shareware games
  335. E-mail address: ingemar@isy.liu.se or ingemar@lysator.liu.se
  336.  
  337. +++++++++++++++++++++++++++
  338.  
  339. >From dwareing@apanix.apana.org.au (David Wareing)
  340. Date: 29 Aug 94 03:21:33 GMT
  341. Organization: Apanix Public Access Unix, +61 8 373 5485 (5 lines)
  342.  
  343. mab22@po.cwru.edu (Mike Balfour) writes:
  344.  
  345. >In article <331iln$4fq@inferno.mpx.com.au>, gkm@jolt.mpx.com.au (Gavin K
  346. >Maxwell) wrote:
  347.  
  348. >> I would like to know peoples impressions of the available sprite 
  349. >> animation libraries.  The two I'm aware of are SpriteWorld and Sprite 
  350. >> Animation Toolkit (SAT), are there any others?  Which is the best?  
  351. >> Are there any gotchas to watch out for?  What are their limitations?
  352.  
  353. >Well, it seems that more people out there are using SpriteWorld, just
  354. >because it was released about a month before SAT.  SpriteWorld is also more
  355. >geared to C, where SAT was originally written for Pascal and has since been
  356. >updated to be usable from C.  Between the two, I'm very biased toward SAT. 
  357. >I beta-tested it for several months, and I found it was very easy to learn,
  358. >easy to use, and just good quick code.  It even makes my bad code run fast
  359. >(who else can claim that?)!  Somebody else recently posted the concern that
  360. >SAT still has warnings in it from the author, Ingemar, about various
  361. >kluges.  I wouldn't be concerned - everything's actually amazingly stable. 
  362. >I should know, I tried some pretty strange things from time to time to try
  363. >to make it break...
  364.  
  365. I'm not sure about the "more people use SpriteWorld" claim, but
  366. there have been several shareware games released lately that use
  367. SAT. And there are several more on the way. Seems to be a fairly
  368. hip and happening product.
  369.  
  370. --
  371. David Wareing
  372. Adelaide, South Australia         dwareing@apanix.apana.org.au
  373. - ------------------------------------------------------------
  374. Freelance Macintosh Games & Multimedia Programming
  375.  
  376. ---------------------------
  377.  
  378. >From jc@ac.dal.ca (JOHN CHRISTIE)
  379. Subject: CW PASCAL vs THINK PASCAL
  380. Date: 18 Aug 94 11:57:04 -0300
  381. Organization: Dalhousie University, Halifax, Nova Scotia, Canada
  382.  
  383. PASCAL keeners read this
  384.  
  385.     Has anyone here used MW PASCAL and THINK PASCAL.  I would be terribly
  386. interested in hearing how they compare from those who have used them.
  387.  
  388.                         Thanks
  389.                         John
  390.  
  391. +++++++++++++++++++++++++++
  392.  
  393. >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!")
  394. Date: Fri, 19 Aug 1994 11:07:15 +0800
  395. Organization: Department of Computer Science, The University of Western Australia
  396.  
  397. In article <1994Aug18.115704.26744@dal1>, jc@ac.dal.ca (JOHN CHRISTIE) wrote:
  398.  
  399. >        Has anyone here used MW PASCAL and THINK PASCAL.  I would be terribly
  400. >interested in hearing how they compare from those who have used them.
  401.  
  402. The big difference between MW Pascal and Think Pascal is that MW Pascal is
  403. going somewhere, and Think Pascal isn't.  MW Pascal still has it's
  404. problems (I'm still on 3.5 so my info may be out of date) but it's
  405. certainly a usable tool.  [For 68K, the PPC one is very much a development
  406. version.]  Think Pascal is, quite simply, the nicest development
  407. environment for the Macintosh.  *However* MW is catching up quick and
  408. Think isn't going anywhere ):  [for a variety of technical and marketting
  409. reasons]  So it'll only be a matter of time before MW wins.
  410. -- 
  411. Quinn "The Eskimo!"      <quinn@cs.uwa.edu.au>     "Support HAVOC!"
  412. Department of Computer Science, The University of Western Australia
  413.  
  414. +++++++++++++++++++++++++++
  415.  
  416. >From drickey@irus.rri.uwo.ca (Daniel W. Rickey)
  417. Date: 18 Aug 1994 19:06:11 GMT
  418. Organization: Imaging Research Labs
  419.  
  420.  
  421. I have tried both.  Actually, I have not had a chance try out the
  422. latest release (CW4).  Version 3.5 was still too buggy to evaluate
  423. properly.  However, it looks like debugging in Think Pascal is much
  424. easier.  CW has a different way of implementing writelns - it
  425. automatically creates an output window like TP, and it takes over the
  426. menu bar.  This makes the writeln mechanism mostly useless for
  427. debugging (as far as I can tell).  It will probably be a long time
  428. before the CW debugger is as nice as the ThinkP debugger...but we can
  429. hope!
  430.  
  431. Moving code from ThinkP to CW is proving to be "interesting".  A few
  432. library functions are missing in CW, although this is not too big of a
  433. deal.  There may be a few other differences in the way typecasting/type
  434. conversions are done between the two compilers.
  435.  
  436. One of the VERY nice features of CW is that it gives compile time
  437. warnings, e.g., variable declared but not used, etc.  The CW pascal and
  438. C compilers are also very similar, unlike Symantec's compilers.  This
  439. should make mixing of C and Pascal code in the same application much
  440. easier.
  441.  
  442.  
  443. Daniel W. Rickey
  444. drickey@.irus.rri.uwo.ca
  445.  
  446. Imaging Research Laboratories
  447. The J.P. Robarts Research Institute
  448. 100 Perth Drive
  449. London, Ontario
  450. CANADA  N6A 5K8
  451.  
  452. +++++++++++++++++++++++++++
  453.  
  454. >From ez033265@ucdavis.edu (Will Iverson)
  455. Date: Thu, 18 Aug 1994 20:25:20 GMT
  456. Organization: University of California, Davis
  457.  
  458. In article <1994Aug18.115704.26744@dal1>, jc@ac.dal.ca (JOHN CHRISTIE) wrote:
  459.  
  460. > PASCAL keeners read this
  461. >         Has anyone here used MW PASCAL and THINK PASCAL.  I would be terribly
  462. > interested in hearing how they compare from those who have used them.
  463. >                                                 Thanks
  464. >                                                 John
  465.  
  466. I've used both, although I've used Think Pascal far more.  I haven't been
  467. able to port my Think Pascal project over to MW Pascal yet because of
  468. (apparent) lack of full SANE support (and maybe something else I haven't
  469. found yet!) - although I'm not sure who to blame.
  470.  
  471. The Think debugger is fully integrated with the editor.  You want to set a
  472. breakpoint?  Just click while you're in the editor.  Lightsbugs lets you
  473. look at memory, data structures, etc.  You can stop your program and
  474. change values, as well as write small pieces of code to be executed
  475. instantly from within the program.  I find the entire programming cycle to
  476. be very short.
  477.  
  478. The debugger for MW is a seperate program, which has advantages &
  479. disadvantages.  The good news is that you can edit a program without
  480. resetting it, but it's a lot more of a pain to to set breakpoints.
  481.  
  482. The Think Editor supports pretty-printing, which means you can basically
  483. forget about formatting and have it do it all for you.
  484.  
  485. The MW Editor is sparser (keyword & comment coloring, no pretty-printing).
  486. It is smarter about things like having the cursor run off the right edge,
  487. however.
  488.  
  489. Think Pascal hasn't seen an update in years. MW Pascal is being updated as
  490. we speak, but doesn't feel as complete.  When I can switch my project over
  491. to MW Pascal, then my whole lab will switch over and we'll get a couple
  492. more copies of MW.
  493.  
  494. Of course, which is better also depends on what you're trying to do.
  495.  
  496. -Will Iverson
  497.  
  498. +++++++++++++++++++++++++++
  499.  
  500. >From philip@cs.uct.ac.za (Philip Machanick)
  501. Date: 19 Aug 1994 12:17:47 +0200
  502. Organization: Computer Science Department, University of Cape Town
  503.  
  504. Will Iverson (ez033265@ucdavis.edu) wrote:
  505. : The Think debugger is fully integrated with the editor.  You want to set a
  506. : breakpoint?  Just click while you're in the editor.  Lightsbugs lets you
  507. : look at memory, data structures, etc.  You can stop your program and
  508. : change values, as well as write small pieces of code to be executed
  509. : instantly from within the program.  I find the entire programming cycle to
  510. : be very short.
  511.  
  512. The Think Pascal environment is wonderful. If only it had been developed
  513. properly - in same ways it is still the best but you can't allow
  514. something to languish for so long without losing your lead eventually.
  515.  
  516. Another thing no one has mentioned in MW's favour: you get a free
  517. C and C++ compiler thrown in with it ;)
  518. --
  519. Philip Machanick                      philip@cs.wits.ac.za
  520. Computer Science Department, University of he Witwatesrand
  521. 2050 Wits, South Africa 27(11)716-3309 fax 339-7965
  522. (at University of Cape Town until November: 27(21)650-4058)
  523.  
  524. +++++++++++++++++++++++++++
  525.  
  526. >From oberst@gov.nt.ca (David Oberst)
  527. Date: Fri, 19 Aug 1994 15:10:03 GMT
  528. Organization: Government of the NWT, Canada
  529.  
  530. In article <3320sb$16f@cs.uct.ac.za> philip@cs.uct.ac.za (Philip Machanick) writes:
  531. >Another thing no one has mentioned in MW's favour: you get a free
  532. >C and C++ compiler thrown in with it ;)
  533. >--
  534. >Philip Machanick                      philip@cs.wits.ac.za
  535. >Computer Science Department, University of he Witwatesrand
  536. >2050 Wits, South Africa 27(11)716-3309 fax 339-7965
  537. >(at University of Cape Town until November: 27(21)650-4058)
  538.  
  539. Of course, to the true Pascalite, this could be considered a drawback
  540. instead of a positive <g>.
  541.  
  542.       David Oberst/GNWT Bureau of Statistics/Yellowknife, NWT, Canada
  543.       oberst@gov.nt.ca
  544.  
  545.  
  546. +++++++++++++++++++++++++++
  547.  
  548. >From peter.lewis@info.curtin.edu.au (Peter N Lewis)
  549. Date: Sat, 20 Aug 1994 17:55:22 +0800
  550. Organization: NCRPDA, Curtin University
  551.  
  552. >version.]  Think Pascal is, quite simply, the nicest development
  553. >environment for the Macintosh.  *However* MW is catching up quick and
  554. >Think isn't going anywhere ):  [for a variety of technical and marketting
  555. >reasons]  So it'll only be a matter of time before MW wins.
  556.  
  557. "a matter of time" likely being somewhere around about the end of the year
  558. when Metrowerks have said they will have their pascal compiler both
  559. supporting objects and compiling to PPC.
  560.    Peter.
  561. -- 
  562. Peter N Lewis <peter.lewis@info.curtin.edu.au> - Macintosh TCP fingerpainter
  563.  
  564. +++++++++++++++++++++++++++
  565.  
  566. >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!")
  567. Date: Sun, 21 Aug 1994 14:52:23 +0800
  568. Organization: Department of Computer Science, The University of Western Australia
  569.  
  570. In article <330bf3$eia@falcon.ccs.uwo.ca>, drickey@irus.rri.uwo.ca (Daniel
  571. W. Rickey) wrote:
  572.  
  573. >Moving code from ThinkP to CW is proving to be "interesting".  A few
  574. >library functions are missing in CW, although this is not too big of a
  575. >deal.  There may be a few other differences in the way typecasting/type
  576. >conversions are done between the two compilers.
  577.  
  578. MW Pascal implements MPW Pascal, not Think Pascal.  I've used both Think
  579. and MPW Pascal a lot and I know whether the differences lie.  But there
  580. are lots of gotchas out there for hard-core Think Pascal users.  Good
  581. luck.
  582. -- 
  583. Quinn "The Eskimo!"      <quinn@cs.uwa.edu.au>     "Support HAVOC!"
  584. Department of Computer Science, The University of Western Australia
  585.  
  586. +++++++++++++++++++++++++++
  587.  
  588. >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!")
  589. Date: Sun, 21 Aug 1994 14:53:05 +0800
  590. Organization: Department of Computer Science, The University of Western Australia
  591.  
  592. In article <3320sb$16f@cs.uct.ac.za>, philip@cs.uct.ac.za (Philip
  593. Machanick) wrote:
  594.  
  595. >Another thing no one has mentioned in MW's favour: you get a free
  596. >C and C++ compiler thrown in with it ;)
  597.        ^^^
  598. I'm not sure whether I'd consider this an advantage (:
  599. -- 
  600. Quinn "The Eskimo!"      <quinn@cs.uwa.edu.au>     "Support HAVOC!"
  601. Department of Computer Science, The University of Western Australia
  602.  
  603. +++++++++++++++++++++++++++
  604.  
  605. >From Vik_Rubenfeld@lamg.com (Vik Rubenfeld)
  606. Date: 21 Aug 1994 13:41:55 GMT
  607. Organization: Los Angeles Macintosh Group BBS
  608.  
  609. Q> MW Pascal implements MPW Pascal, not Think Pascal. I've used both
  610. Q> Think and MPW Pascal a lot and I know whether the differences lie.
  611. Q> But there are lots of gotchas out there for hard-core Think Pascal
  612. Q> users. Good luck.
  613.  
  614. Could you post a list describing some of the differences? Thanks in advance.
  615.  
  616. +++++++++++++++++++++++++++
  617.  
  618. >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!")
  619. Date: Mon, 22 Aug 1994 10:55:49 +0800
  620. Organization: Department of Computer Science, The University of Western Australia
  621.  
  622. In article <1088487199.6340968@lamgnet.lamg.com>, Vik_Rubenfeld@lamg.com wrote:
  623.  
  624. >Could you post a list describing some of the differences? Thanks in advance.
  625.  
  626. This is covered in one of the appendices in the Think Pascal reference manual.
  627.  
  628. My personal favourite gotcha is the differences in the built-in string
  629. function copy.  MPW (and MW) returns '' if any of the parameters are out
  630. of bounds whereas Think makes a best effort.
  631.  
  632. eg copy('abcd', 3, 255) returns '' in MPW and MW and 'cd' in Think.
  633. -- 
  634. Quinn "The Eskimo!"      <quinn@cs.uwa.edu.au>     "Support HAVOC!"
  635. Department of Computer Science, The University of Western Australia
  636.  
  637. +++++++++++++++++++++++++++
  638.  
  639. >From trentmd@scooby.beloit.edu (Michael Trent)
  640. Date: 22 Aug 1994 23:08:50 GMT
  641. Organization: Beloit College 
  642.  
  643. Quinn "The Eskimo! (quinn@cs.uwa.edu.au) wrote:
  644. : In article <1994Aug18.115704.26744@dal1>, jc@ac.dal.ca (JOHN CHRISTIE) wrote:
  645.  
  646. : >        Has anyone here used MW PASCAL and THINK PASCAL.  I would be terribly
  647. : >interested in hearing how they compare from those who have used them.
  648.  
  649. : The big difference between MW Pascal and Think Pascal is that MW Pascal is
  650. : going somewhere, and Think Pascal isn't. 
  651.  
  652. AMEN BROTHER!
  653.  
  654. As cool as it is to have a "We will not be Emulated!" c/c++ compiler, it was
  655. a new Pascal that drove me to order MWCW Gold!  I've spent too much time
  656. fighting the age of THINK Pascal to enjoy it anymore.
  657.  
  658. --
  659.       Mike Trent        |  Macintosh Specialist  |   Beloit College
  660. trentmd@stu.beloit.edu  |   Academic Computing   |  Beloit Wisconsin
  661.  
  662. +++++++++++++++++++++++++++
  663.  
  664. >From kn@doc.ic.ac.uk (Keng Ng)
  665. Date: 23 Aug 1994 11:46:16 GMT
  666. Organization: Imperial College, Dept. of Computing
  667.  
  668. In article <peter.lewis-2008941755220001@rocky.curtin.edu.au>,
  669. peter.lewis@info.curtin.edu.au (Peter N Lewis) wrote:
  670.  
  671. > >version.]  Think Pascal is, quite simply, the nicest development
  672. > >environment for the Macintosh.  *However* MW is catching up quick and
  673. > >Think isn't going anywhere ):  [for a variety of technical and marketting
  674. > >reasons]  So it'll only be a matter of time before MW wins.
  675. > "a matter of time" likely being somewhere around about the end of the year
  676. > when Metrowerks have said they will have their pascal compiler both
  677. > supporting objects and compiling to PPC.
  678.              ^^^^^^^
  679.  
  680. Does that mean that we'll be able to use it for MacApp 2.0.1 projects ?
  681.  
  682. -Keng
  683. _________________________________________________________________
  684.  
  685.  Keng T. Ng                      Email:   kn@doc.ic.ac.uk
  686.  Imperial College,
  687.  Dept. of Computing,             Phone:   +44 71 594 8287
  688.  180 Queen's Gate,               Fax:     +44 71 581 8024
  689.  London SW7 2BZ, UK
  690. _________________________________________________________________
  691.  
  692. +++++++++++++++++++++++++++
  693.  
  694. >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!")
  695. Date: Thu, 25 Aug 1994 11:30:54 +0800
  696. Organization: Department of Computer Science, The University of Western Australia
  697.  
  698. In article <kn-2308941245290001@146.169.14.31>, kn@doc.ic.ac.uk (Keng Ng) wrote:
  699.  
  700. >Does that mean that we'll be able to use it for MacApp 2.0.1 projects ?
  701.  
  702. For PPC code?  Unlikely without a lot of work.  MacApp 2.0.1 is full of
  703. lots of skanky things that make taking it native tricky.  Specifically:
  704. exception handling.
  705. -- 
  706. Quinn "The Eskimo!"        "Scout in a can. Simple, cheap, easy
  707.                             to use and it's expendable!"
  708.  
  709. +++++++++++++++++++++++++++
  710.  
  711. >From peter.lewis@info.curtin.edu.au (Peter N Lewis)
  712. Date: Thu, 25 Aug 1994 12:38:05 +0800
  713. Organization: NCRPDA, Curtin University
  714.  
  715. In article <quinn-2208941055490001@edu-dynamic1.educ.ecel.uwa.edu.au>,
  716. quinn@cs.uwa.edu.au (Quinn "The Eskimo!") wrote:
  717.  
  718. >My personal favourite gotcha is the differences in the built-in string
  719. >function copy.  MPW (and MW) returns '' if any of the parameters are out
  720. >of bounds whereas Think makes a best effort.
  721. >
  722. >eg copy('abcd', 3, 255) returns '' in MPW and MW and 'cd' in Think.
  723.  
  724. Yeah, this is mind nummingly anoying (although not quite annoying as DR/2s
  725. behaviour of copy :-)
  726.  
  727.  function TPcopy (source: string; start, count: integer): string;
  728.   var
  729.    i: integer;
  730.  begin
  731.   if (start < 1) then begin
  732.    count := count - (1 - start);
  733.    start := 1;
  734.   end;
  735.   if start + count > length(source) then begin
  736.    count := length(source) - start + 1;
  737.   end;
  738.   if count < 0 then begin
  739.    count := 0;
  740.   end;
  741.   source[0] := chr(count);
  742.   BlockMove(@source[start], @source[1], count);
  743.   TPcopy := source;
  744.  end;
  745.  
  746. Non optiomal, but who cares?
  747.  
  748. Enjoy,
  749.    Peter.
  750. -- 
  751. Peter N Lewis <peter.lewis@info.curtin.edu.au> - Macintosh TCP fingerpainter
  752.  
  753. +++++++++++++++++++++++++++
  754.  
  755. >From ingemar@lysator.liu.se (Ingemar Ragnemalm)
  756. Date: 28 Aug 1994 09:54:00 GMT
  757. Organization: (none)
  758.  
  759. peter.lewis@info.curtin.edu.au (Peter N Lewis) writes:
  760.  
  761. >>version.]  Think Pascal is, quite simply, the nicest development
  762. >>environment for the Macintosh.  *However* MW is catching up quick and
  763. >>Think isn't going anywhere ):  [for a variety of technical and marketting
  764. >>reasons]  So it'll only be a matter of time before MW wins.
  765.  
  766. >"a matter of time" likely being somewhere around about the end of the year
  767. >when Metrowerks have said they will have their pascal compiler both
  768. >supporting objects and compiling to PPC.
  769.  
  770. I doubt it. Even though PPC support is a strong point, they are so much
  771. behind in all other areas. No auto-indentation, not even on command. The
  772. debugger is a pain in the ass compared to Lightsbug - and where are
  773. Observe and Instant, my two favourite features? The debugger doesn't even
  774. seem to catch any errors to speak of. I hate when the program stops running,
  775. and the debugger says nothing, and I don't even know where it stopped.
  776. And the resource file is handled in the BRAIN-DAMAGED way that Think C used
  777. up to version 5.
  778.  
  779. I hope they can make a decent product of it, but I can see my productivity
  780. going down... Back to the Lightspeed C days, when debugging took several
  781. times longer, since there were no decent debugger arund.
  782.  
  783. --
  784. - -
  785. Ingemar Ragnemalm, PhD
  786. Image processing, Mac shareware games
  787. E-mail address: ingemar@isy.liu.se or ingemar@lysator.liu.se
  788.  
  789. +++++++++++++++++++++++++++
  790.  
  791. >From ingemar@lysator.liu.se (Ingemar Ragnemalm)
  792. Date: 28 Aug 1994 10:00:26 GMT
  793. Organization: (none)
  794.  
  795. Vik_Rubenfeld@lamg.com (Vik Rubenfeld) writes:
  796.  
  797. >Q> MW Pascal implements MPW Pascal, not Think Pascal. I've used both
  798. >Q> Think and MPW Pascal a lot and I know whether the differences lie.
  799. >Q> But there are lots of gotchas out there for hard-core Think Pascal
  800. >Q> users. Good luck.
  801.  
  802. >Could you post a list describing some of the differences? Thanks in advance.
  803.  
  804. Some obvious differences are that no managers are automatically used (thus,
  805. I'm building up a set of stuff to "uses" in all files - finding out exactly
  806. what standard managers to use is a pain), and initializations aren't
  807. automatic. All QuickDraw globals are in a "qd" record.
  808.  
  809. --
  810. - -
  811. Ingemar Ragnemalm, PhD
  812. Image processing, Mac shareware games
  813. E-mail address: ingemar@isy.liu.se or ingemar@lysator.liu.se
  814.  
  815. +++++++++++++++++++++++++++
  816.  
  817. >From howarth@bromo.med.uth.tmc.edu (Jack W. Howarth)
  818. Date: 28 Aug 1994 18:28:52 GMT
  819. Organization: University of Texas Medical School
  820.  
  821. In article <33pn7q$l5h@newsy.ifm.liu.se>
  822. ingemar@lysator.liu.se (Ingemar Ragnemalm) writes:
  823.  
  824. > Some obvious differences are that no managers are automatically used (thus,
  825. > I'm building up a set of stuff to "uses" in all files - finding out exactly
  826. > what standard managers to use is a pain), and initializations aren't
  827. > automatic. All QuickDraw globals are in a "qd" record.
  828.  
  829. Are you sure that some of your complaints are directed at the new
  830. Universal Headers from Apple and not MW Pascal itself?
  831.  
  832. Jack W. Howarth, Ph.D.                Univ. of Texas Medical School
  833. Research Fellow                                      P.O. Box 20708
  834. Department of Biochemistry                     Houston, Texas 77225
  835.  
  836. +++++++++++++++++++++++++++
  837.  
  838. >From peter.lewis@info.curtin.edu.au (Peter N Lewis)
  839. Date: Mon, 29 Aug 1994 10:10:52 +0800
  840. Organization: NCRPDA, Curtin University
  841.  
  842. >Some obvious differences are that no managers are automatically used (thus,
  843. >I'm building up a set of stuff to "uses" in all files - finding out exactly
  844. >what standard managers to use is a pain), and initializations aren't
  845.  
  846. ObiWan will tell you which unit to include for a given procedure.  I have
  847. the same problem, but a few compiles and it's fixed.  Also, you can use
  848. stuff like this:
  849.  
  850. {$IFC undefined THINK_Pascal}
  851.    uses
  852.       Events;
  853. {$ENDC}
  854.  
  855. To avoid having to include all the dummy unix in THINK Pascal.
  856.    Peter.
  857. -- 
  858. Peter N Lewis <peter.lewis@info.curtin.edu.au> - Macintosh TCP fingerpainter
  859.  
  860. ---------------------------
  861.  
  862. >From chrism@col.hp.com (Chris Magnuson)
  863. Subject: Items in system menu bar
  864. Date: 17 Aug 1994 20:17:44 GMT
  865. Organization: HP Colorado Springs Division
  866.  
  867.   I was reading about the Menu Manager last night, trying to figure out
  868.   how to stick icons in the Finder's menu bar (right up there next to 
  869.   the balloon, for example).  Anyone have any ideas on how to do this?
  870.   Is this considered Menu #0 and you just GetMenuHandle() on that?
  871.  
  872.   Hmm.  Any hints would be appreciated.
  873.  
  874.   Thanks,
  875.   Chris Magnuson
  876.   chrism@col.hp.com
  877.  
  878. +++++++++++++++++++++++++++
  879.  
  880. >From spencerl@crl.com (Spencer Low)
  881. Date: Wed, 17 Aug 1994 15:33:08 -0800
  882. Organization: LowTek Creations
  883.  
  884. In article <32tr98$pfg@hp-col.col.hp.com>, chrism@col.hp.com (Chris
  885. Magnuson) wrote:
  886. >   I was reading about the Menu Manager last night, trying to figure out
  887. >   how to stick icons in the Finder's menu bar (right up there next to 
  888. >   the balloon, for example).  Anyone have any ideas on how to do this?
  889. >   Is this considered Menu #0 and you just GetMenuHandle() on that?
  890.  
  891. If you want to install a System Menu (i.e. ColorSwitch, OtherMenu, Help
  892. menu, Application menu, etc.), check out the "star-menu" source at UMICH.
  893. Or read up on TSM menus in Inside Mac: Text.
  894.  
  895. Spencer
  896.  
  897. +++++++++++++++++++++++++++
  898.  
  899. >From Jens Alfke <jens_alfke@powertalk.apple.com>
  900. Date: Thu, 25 Aug 1994 00:27:15 GMT
  901. Organization: Apple Computer
  902.  
  903. Chris Magnuson, chrism@col.hp.com writes:
  904. >   I was reading about the Menu Manager last night, trying to figure out
  905. >   how to stick icons in the Finder's menu bar (right up there next to 
  906. >   the balloon, for example).  Anyone have any ideas on how to do this?
  907. >   Is this considered Menu #0 and you just GetMenuHandle() on that?
  908.  
  909. There are really two things you want:
  910. (1) How to give a menu an icon as a title. Simple: It has to have a five
  911. character name, of which the first byte is '\01' (Ascii 01) and the other
  912. four are a handle to an icon suite. Needless to say, don't dispose the icon
  913. suite before the menu goes away.
  914. (2) How to put a menu on the right side of the menu bar. There's a particular
  915. range of negative menu IDs that signal a system menu; if you add a menu with
  916. such an ID it automatically goes on the right side, and it automatically will
  917. be added to the menu bar of every app that's launched. This means it's best
  918. to install such menus as soon as the menu bar first comes up; e.g. by
  919. patching DrawMenuBar. Make sure you load the icon into the System heap, of
  920. course, otherwise it'll be disposed when the current app quits.
  921.  
  922. I believe there is sample code somplace showing how to do this.
  923. Disclaimer: None of this stuff is supported by Apple (though it's cool) and
  924. these techniques may break in the future.
  925.  
  926. --Jens Alfke                           jens_alfke@powertalk.apple.com
  927.                    "A man, a plan, a yam, a can of Spam ... Bananama!"
  928.  
  929. +++++++++++++++++++++++++++
  930.  
  931. >From rollin@newton.apple.com (Keith Rollin)
  932. Date: Sun, 28 Aug 1994 18:39:36 -0800
  933. Organization: Apple ][ -> Mac -> Taligent -> Newton -> Windows?
  934.  
  935. In article <32tr98$pfg@hp-col.col.hp.com>, chrism@col.hp.com (Chris
  936. Magnuson) wrote:
  937.  
  938. >  I was reading about the Menu Manager last night, trying to figure out
  939. >  how to stick icons in the Finder's menu bar (right up there next to 
  940. >  the balloon, for example).  Anyone have any ideas on how to do this?
  941. >  Is this considered Menu #0 and you just GetMenuHandle() on that?
  942.  
  943.  
  944. The following tips concerning being compatible with future Mac OSes were
  945. distributed (I think) at the last WWDC:
  946.  
  947.  
  948. 7.  Extensions that try to modify menus in applications without their
  949. knowledge will no longer work. 
  950.  
  951. 8.  Extensions that install menus in the system portion of the menu bar
  952. will break if they access Menu Manager data without using the Menu Manager
  953. API.
  954.  
  955. 9.  Extensions that augment or override the behavior of the Apple menu
  956. (like adding hierarchical menus) will break.  
  957.  
  958.  
  959. That said, here's an INIT written by someone in Mac DTS that does what
  960. you're asking. Given the above warnings, I would consider the following
  961. hack to be unsupported, but about as best as you can do given today's
  962. Toolbox API.
  963.  
  964.  
  965.  
  966. ;   Sample INIT that puts up a system wide menu and installs a handler for it.
  967. ;   The general idea of this is that it waits for the system to install a
  968. system menu and then
  969. ;   when that menu is installed it installs its own menu. The patch to
  970. SystemMenu is what is
  971. ;   used to determine what to do when an item is selected.
  972. ;
  973. ;   Use the following MPW commands to build the INIT:
  974. ;
  975. ;   asm SampleINIT.a -o SampleINIT.a.o
  976. ;   Link -o SampleINIT -rt INIT=128 -ra Main=resSysHeap -t INIT SampleINIT.a.o
  977. ;   duplicate SampleINIT "{SystemFolder}Extensions:aSampleINIT"
  978. ;
  979. ;   Hack courtesy of Apple Developer Tech Support
  980. ;   Change History:
  981. ;   12/10/93    JLM     Created the INIT and made items beep with sysbeep
  982. ;
  983.  
  984.             PRINT   PUSH,OFF            ; don't print any of this stuff
  985.             
  986.             INCLUDE 'ToolEqu.a'
  987.             INCLUDE 'Traps.a'
  988.             INCLUDE 'PackMacs.a'
  989.             INCLUDE 'QuickEqu.a'
  990.             INCLUDE 'SysEqu.a'
  991.             
  992.             PRINT   POP             ; restore the PRINT options
  993.  
  994. theStub         proc    Export
  995.                 Import  ENTRY
  996.                 bra     ENTRY
  997.                 EndP
  998.                 
  999. MyGlobals       Record  0
  1000. OldInsertMenu   ds.L    1
  1001. OldSystemMenu   ds.L    1
  1002. MyMenuHand      ds.L    1
  1003. MyMenuID        ds.W    1
  1004.                 EndR
  1005.                 
  1006. tenderID        equ     $BF99       ; this looks like a good start  
  1007. Globals         proc    Export
  1008.                 ds      MyGlobals
  1009.                 Export  MyMenuStr
  1010. MyMenuStr       dc      'Item1;Item2'       ;
  1011.                 Export  MyMenuTitle
  1012. MyMenuTitle     dc      'SMU'               ; and our menu
  1013.                 EndP
  1014.             
  1015. MyInsertMenu    proc    Export
  1016. InsMenuFrame    Record  {xA6Link},DECR
  1017. xParmBegin      equ     *
  1018. theMenu         ds.L    1
  1019. before          ds.W    1
  1020. xParmSize       equ     xParmBegin-*
  1021. xRetAddr        ds.L    1
  1022. xJumpThru       ds.L    1                   ; store the real address here
  1023. on stack for unwinding
  1024. xA6Link         ds.L    1
  1025. * Insert local vars here
  1026. ZoneSave        ds.L    1
  1027. xLocalSize      equ     *
  1028.                 endr
  1029.                 with    InsMenuFrame,MyGlobals
  1030.                 clr.L   -(sp)               ; for the return address of
  1031. this routine
  1032.                 LINK    A6,#xLocalSize
  1033.                 movem.L D0-D2/A0-A4,-(sp)   ; save these temp registers
  1034.                 lea     Globals,A4          ; get our globals pointer so
  1035. we can test further
  1036.                 move.L  theMenu(A6),A0          ; get the menu handle
  1037. being installed
  1038.                 move.L  (A0),A0             ; deref it
  1039.                 tst.W   (A0)                ; see if its a system menu
  1040.                 bpl.s   @IgnorePatch        ; if so ignore the patch stuff
  1041.                 move.W  MyMenuID(A4),D0
  1042.                 tst.W   D0                  ; see if we are installed yet...
  1043.                 beq.s   @InstallMe          ; nope better install
  1044. ourselves first
  1045.                 cmp.W   (A0),D0             ; see if our menu has the same
  1046. ID as this menu
  1047.                 bne.s   @IgnorePatch        ; it does not, we can leave now
  1048.  
  1049. @IDConflict
  1050. ; if we get here the system menu ID number we have choosen is in conflict
  1051. with a system menu
  1052. ; used by the system. We could try to change our number or bail out. I
  1053. choose bailing out
  1054. ; for this example. The proper thing to do might be to examine the menu
  1055. list and try a different
  1056. ; number.
  1057.                 move.W  MyMenuID(A4),-(sp)  ; first delete the menu from
  1058. the menu bar
  1059.                 _DeleteMenu                 ; ok now the menu is deleted
  1060.                 move.W  #1,MyMenuID(A4)     ; and reset our menu ID to not
  1061. ever be a system menu but be non-zero
  1062.                 move.L  MyMenuHand(A4),-(sp)
  1063.                 _DisposeMenu                ; and dump the menu itself
  1064.                 move.L  #1,MyMenuHand(A4)   ; and zots the menu handle as well
  1065.                 bra.s   @ignorePatch        ; and exit
  1066. @InstallMe
  1067.                 move.L  theZone,zoneSave(A6)
  1068.                 move.L  SysZone,A0
  1069.                 _SetZone                    ; insure that the new menu
  1070. goes into the system heap
  1071.  
  1072.                 clr.L   -(sp)               ; first create our menu
  1073.                 move.W  #tenderID,-(sp)     ; move our projected ID on the stack
  1074.                 pea     MyMenuTitle ; and push our title pointer
  1075.                 _NewMenu
  1076.                 move.L  (sp),MyMenuHand(A4) ; set up our menu handle in memory
  1077.                 pea     MyMenuStr           
  1078.                 _AppendMenu                 ; now we have built us a menu
  1079.                 move.W  #tenderID,MyMenuID(A4)
  1080.                 
  1081.                 move.L  zoneSave(A6),A0
  1082.                 _SetZone                    ; switch back to the app heap
  1083.                 
  1084.                 move.L  MyMenuHand(A4),-(sp)
  1085.                 move.W  #tenderID,-(sp)
  1086.                 move.L  OldInsertMenu(A4),A0
  1087.                 jsr     (A0)                ; call the real insert menu to
  1088. insert us
  1089. ; ok, now we are inserted and we will work just fine...
  1090. ;
  1091.  
  1092. @ignorePatch
  1093. ; dummy up the stack to have the address of the real patch so's I can use
  1094. RTS to jump to
  1095. ; the real patch instead of A0
  1096.                 move.L  OldInsertMenu(A4),xJumpThru(A6)
  1097.                 movem.L (sp)+,D0-D2/A0-A4   ; restore the stack
  1098.                 unlk    A6                  ; and A6
  1099.                 rts                         ; now call back the original
  1100.                 EndP
  1101.                 
  1102. MySystemMenu    proc    Export
  1103. InsMenuFrame    Record  {xA6Link},DECR
  1104. xParmBegin      equ     *
  1105. theItem         ds.W    1
  1106. theMenuID       ds.W    1
  1107. xParmSize       equ     xParmBegin-*
  1108. xRetAddr        ds.L    1
  1109. xJumpThru       ds.L    1                   ; store the real address here
  1110. on stack for unwinding
  1111. xA6Link         ds.L    1
  1112. * Insert local vars here
  1113. xLocalSize      equ     *
  1114.                 EndR
  1115.                 with    InsMenuFrame,MyGlobals
  1116.                 clr.L   -(sp)               ; for the return address of
  1117. this routine
  1118.                 LINK    A6,#xLocalSize
  1119.                 movem.L D0-D2/A0-A4,-(sp)   ; save these temp registers
  1120.                 lea     Globals,A4          ; get our globals pointer so
  1121. we can test further
  1122.                 move.W  theMenuID(A6),D0
  1123.                 cmp.W   MyMenuID(A4),D0     ; see if its our menu
  1124.                 bne.s   @ignorePatch        ; if not simply call thru to
  1125. he other side
  1126. ; else this is our menu, for right now we will simply beep at the user
  1127.                 move.L  #$00050005,-(sp)    ; set up to beep twice
  1128.                 _Sysbeep
  1129.                 _SysBeep
  1130. ; and since we handled the menu we will now return to the caller
  1131.                 movem.L (sp)+,D0-D2/A0-A4   ; restore the stack
  1132.                 unlk    A6                  ; and A6
  1133.                 addQ.L  #4,sp               ; remove the long we pushed on
  1134. the stack earlier
  1135.                 move.L  (sp)+,(sp)          ; and remove the return
  1136. address and place it on top of the parms
  1137.                 rts                         ; and return to our regularly
  1138. scheduled app.
  1139.                 
  1140. @ignorePatch
  1141. ; dummy up the stack to have the address of the real patch so's I can use
  1142. RTS to jump to
  1143. ; the real patch instead of A0
  1144.                 move.L  OldSystemMenu(A4),xJumpThru(A6)
  1145.                 movem.L (sp)+,D0-D2/A0-A4   ; restore the stack
  1146.                 unlk    A6                  ; and A6
  1147.                 rts                         ; now call back the original
  1148.                 EndP
  1149.     
  1150. ENTRY           proc    export
  1151.  
  1152.                 With    MyGlobals
  1153.                 
  1154.                 _Debugger                   ; enter the debugger so's I
  1155. can test this stuff out
  1156.                 movem.L A0-A5/D0-D7,-(sp)   ; save regs to be safe
  1157.                 lea     Globals,A4          ; set up our globals            
  1158.                 
  1159.                 move.L  SysZone,A0
  1160.                 _SetZone
  1161.                 
  1162.                 lea     theStub,A0          ; now get our handle detach
  1163. and lock it down its already
  1164.                 _RecoverHandle              ; in the system heap
  1165.                 move.L  A0,-(sp)
  1166.                 _DetachResource             ; and detach the bad boy...
  1167.                 
  1168.                 Move.W  #$A935,D0           ; now insert my patch to
  1169. InsertMenu $A935
  1170.                 _GetTrapAddress
  1171.                 move.L  A0,OldInsertMenu(A4)
  1172.                 
  1173.                 lea     MyInsertMenu,A0
  1174.                 Move.W  #$A935,D0
  1175.                 _SetTrapAddress
  1176.                 
  1177.                 Move.W  #$A9B5,D0           ; now insert my patch to
  1178. SystemMenu $A9B5
  1179.                 _GetTrapAddress
  1180.                 move.L  A0,OldSystemMenu(A4)
  1181.                 
  1182.                 lea     MySystemMenu,A0
  1183.                 Move.W  #$A9B5,D0
  1184.                 _SetTrapAddress
  1185.                 
  1186.                 moveQ   #0,D0
  1187.                 move.W  D0,MyMenuID(A4)
  1188.                 Move.L  D0,MyMenuHand(A4)
  1189.                 move.L  ApplZone,A0
  1190.                 _SetZone
  1191.                 
  1192.                 movem.L (sp)+,A0-A5/D0-D7   ; save regs to be safe
  1193.         
  1194.                 rts
  1195.                 EndP
  1196.  
  1197.                     
  1198.                 End
  1199.  
  1200. - --------------------------------------------------------------------------
  1201. Keith Rollin --- Phantom Programmer --- Apple Computer, Inc. --- Team Newton
  1202.  
  1203. ---------------------------
  1204.  
  1205. >From zorro@cats.ucsc.edu (zorro)
  1206. Subject: Text searches.
  1207. Date: 16 Aug 1994 17:52:29 GMT
  1208. Organization: University of California; Santa Cruz
  1209.  
  1210.  
  1211.  
  1212. Constantly I find myself in the situation that Dina described... not knowing
  1213. where to look for a particulat #define, variable, or function.
  1214. So what I end up doing is uploading whole directories to my trusty Sparc
  1215. and using the 'grep' command. I realize this is wrong on a very basic level
  1216. and so what I want to ask is, does anyone know of an MPW Tool that duplicates
  1217. the functionality of 'grep'?
  1218. I could write one myself, all it would have to do is look through .c and .h
  1219. files for a text pattern, but I would prefer it if I didn't have to.
  1220.  
  1221. So, has anyone out there implemented 'grep'??
  1222.  
  1223. - Dan
  1224.  
  1225.  
  1226. +++++++++++++++++++++++++++
  1227.  
  1228. >From mcrawfor@bio.ri.ccf.org (Mike Crawford)
  1229. Date: Tue, 16 Aug 1994 19:08:16 GMT
  1230. Organization: The Cleveland Clinic Foundation
  1231.  
  1232. In article 2pg@darkstar.UCSC.EDU, zorro@cats.ucsc.edu (zorro) writes:
  1233. >
  1234. >
  1235. >Constantly I find myself in the situation that Dina described... not knowing
  1236. >where to look for a particulat #define, variable, or function.
  1237. >So what I end up doing is uploading whole directories to my trusty Sparc
  1238. >and using the 'grep' command. I realize this is wrong on a very basic level
  1239. >and so what I want to ask is, does anyone know of an MPW Tool that duplicates
  1240. >the functionality of 'grep'?
  1241. >I could write one myself, all it would have to do is look through .c and .h
  1242. >files for a text pattern, but I would prefer it if I didn't have to.
  1243. >
  1244. >So, has anyone out there implemented 'grep'??
  1245. >
  1246. >- Dan
  1247. >
  1248.  
  1249.  
  1250. MPW† has a tool called 'search'  which functions just like the 'grep' command.
  1251.  
  1252. Ex.
  1253.  
  1254. search "Str255" {CIncludes}*.h   // searches all .h files in the current directory for
  1255.                 // any occurance of 'Str255'
  1256.  
  1257. ****† NOTE, the wildcard character is not an asterisk, it's a double skwiggly line and
  1258. can be created by the  option-x  key combination... I just couldn't duplicate it in
  1259. this message.  Sorry for the crudity of my example.
  1260.  
  1261. the search command is very useful... I use it daily
  1262.  
  1263. good luck
  1264.  
  1265. mwc
  1266.  
  1267. - ----------
  1268. Internet: mcrawfor@bio.ri.ccf.org
  1269. AOL:      Marlin89@aol.com
  1270. eWorld:   Marlin89@eworld.com
  1271. - ----------
  1272. "And the people all said, "Sit down!" your rockin the boat..."
  1273. - ----------
  1274.  
  1275.  
  1276. +++++++++++++++++++++++++++
  1277.  
  1278. >From siegel@netcom.com (Rich Siegel)
  1279. Date: Tue, 16 Aug 1994 23:01:36 GMT
  1280. Organization: Bare Bones Software
  1281.  
  1282. In article <32quct$2pg@darkstar.UCSC.EDU> zorro@cats.ucsc.edu (zorro) writes:
  1283. >So what I end up doing is uploading whole directories to my trusty Sparc
  1284. >and using the 'grep' command. I realize this is wrong on a very basic level
  1285. >and so what I want to ask is, does anyone know of an MPW Tool that duplicates
  1286. >the functionality of 'grep'?
  1287. >
  1288. >So, has anyone out there implemented 'grep'??
  1289.  
  1290. Time to read the fine manual, particularly the chapter which describes
  1291. the "Search" tool. The MPW intrinsic "Help" has also proven safe and
  1292. effective when used as directed, particularly when combined with the
  1293. words "Expressions" and "Search".
  1294.  
  1295. R.
  1296. -- 
  1297. Rich Siegel % siegel@netcom.com    % President & CEO, Bare Bones Software Inc.
  1298. --> For information about BBEdit, finger bbedit@world.std.com <--
  1299.  
  1300. +++++++++++++++++++++++++++
  1301.  
  1302. >From bobo@reed.edu (Eric Bowman)
  1303. Date: 17 Aug 1994 03:56:27 GMT
  1304. Organization: Reed College,  Portland, Oregon
  1305.  
  1306. In article <32quct$2pg@darkstar.ucsc.edu>, zorro <zorro@cats.ucsc.edu> wrote:
  1307. >Constantly I find myself in the situation that Dina described... not knowing
  1308. >where to look for a particulat #define, variable, or function.
  1309. >So what I end up doing is uploading whole directories to my trusty Sparc
  1310. >and using the 'grep' command. I realize this is wrong on a very basic level
  1311. >and so what I want to ask is, does anyone know of an MPW Tool that duplicates
  1312. >the functionality of 'grep'?
  1313. >I could write one myself, all it would have to do is look through .c and .h
  1314. >files for a text pattern, but I would prefer it if I didn't have to.
  1315.  
  1316. Well, "Search" has all the functionality of "grep", except it uses MPW's 
  1317. regular expression syntax instead of unix's.  Other than that, though, it 
  1318. works great; better, even, than grep since it's so easy to jump to the 
  1319. results of the search by double-clicking lines spewed out by search.
  1320.  
  1321. I just used it to do a very nasty search:  I needed to "touch" every 
  1322. source file with an ASSERT, Debugger, or DebugStr (just got ETO 15!)...to 
  1323. do this you need only do the following:
  1324.  
  1325. setfile -m . \d
  1326. `grep -s /[AD][Se][Sb][Eu][Rg][TSg][te]*[r]*\d(/ \x.cp | \d
  1327. streamedit -d -e '/File \d"(\x)\r1\d"\d;/ print \r1' | \d
  1328. sort -unique`
  1329.  
  1330. where
  1331. \d = option-d
  1332. \r = option-r
  1333. \x = option-x
  1334.  
  1335. Oh yeah, I have search aliased as "grep" :)
  1336.  
  1337. Just try and do *that* in any other IDE...
  1338.  
  1339. cheers,
  1340. bobo
  1341.  
  1342.  
  1343. +++++++++++++++++++++++++++
  1344.  
  1345. >From Bruce@hoult.actrix.gen.nz (Bruce Hoult)
  1346. Date: Wed, 17 Aug 1994 15:26:30 +1200 (NZST)
  1347. Organization: (none)
  1348.  
  1349. zorro@cats.ucsc.edu (zorro) writes:
  1350. > Constantly I find myself in the situation that Dina described... not knowing
  1351. > where to look for a particulat #define, variable, or function.
  1352. > So what I end up doing is uploading whole directories to my trusty Sparc
  1353. > and using the 'grep' command. I realize this is wrong on a very basic level
  1354. > and so what I want to ask is, does anyone know of an MPW Tool that duplicates
  1355. > the functionality of 'grep'?
  1356. > I could write one myself, all it would have to do is look through .c and .h
  1357. > files for a text pattern, but I would prefer it if I didn't have to.
  1358.  
  1359. What's wrong with "search"?  Name too obscure, or something?
  1360.  
  1361.    search CloseWindow "{cincludes}"≈.h
  1362.  
  1363. -- Bruce
  1364.  
  1365. +++++++++++++++++++++++++++
  1366.  
  1367. >From zstern@adobe.com (Zalman Stern)
  1368. Date: Wed, 17 Aug 1994 07:57:22 GMT
  1369. Organization: Adobe Systems Incorporated
  1370.  
  1371.  writes
  1372. > zorro@cats.ucsc.edu (zorro) writes:
  1373. > > Constantly I find myself in the situation that Dina described... not  
  1374. knowing
  1375. > > where to look for a particulat #define, variable, or function.
  1376. > > So what I end up doing is uploading whole directories to my trusty Sparc
  1377. > > and using the 'grep' command. I realize this is wrong on a very basic  
  1378. level
  1379. > > and so what I want to ask is, does anyone know of an MPW Tool that  
  1380. duplicates
  1381. > > the functionality of 'grep'?
  1382. > > I could write one myself, all it would have to do is look through .c and  
  1383. h
  1384. > > files for a text pattern, but I would prefer it if I didn't have to.
  1385. > What's wrong with "search"?  Name too obscure, or something?
  1386.  
  1387. There is a port of the GNU grep command to MPW. I picked it up off  
  1388. ftp.apple.com a year or two ago. Its faster and has more functionality than  
  1389. search. The Mac is still relatively slow at this sort of thing compared to a  
  1390. decent UNIX box though.
  1391. --
  1392. Zalman Stern           zalman@adobe.com            (415) 962 3824
  1393. Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
  1394. It seems like once people grow up, they have no idea what's cool. - Calvin
  1395.  
  1396. +++++++++++++++++++++++++++
  1397.  
  1398. >From Bruce@hoult.actrix.gen.nz (Bruce Hoult)
  1399. Date: Thu, 18 Aug 1994 03:11:36 +1200 (NZST)
  1400. Organization: (none)
  1401.  
  1402. zstern@adobe.com (Zalman Stern) writes:
  1403. > There is a port of the GNU grep command to MPW. I picked it up off  
  1404. > ftp.apple.com a year or two ago. Its faster and has more functionality than  
  1405. > search. The Mac is still relatively slow at this sort of thing compared to a  
  1406. > decent UNIX box though.
  1407.  
  1408. "search" used to be slow.  I wrote my own tool to search for literal strings
  1409. and it ran at 1.5 MB/sec on a Q700 with Quantum LPS240 HD, searching 40 MB of
  1410. 200K files, while "search" ran at 300 KB/sec or so.
  1411.  
  1412. Then, a year or two ago, I got a new version of MPW and the search ran at the
  1413. same 1.5 MB/sec as my simple program did.  I've gone back to MPW Search ever
  1414. since.
  1415.  
  1416. -- Bruce
  1417.  
  1418. +++++++++++++++++++++++++++
  1419.  
  1420. >From becker@Xenon.Stanford.EDU (Denizen of the Deep)
  1421. Date: 17 Aug 1994 16:35:59 GMT
  1422. Organization: Computer Science Department, Stanford University.
  1423.  
  1424. In article <32quct$2pg@darkstar.UCSC.EDU>, zorro <zorro@cats.ucsc.edu> wrote:
  1425. >
  1426. >
  1427. >Constantly I find myself in the situation that Dina described... not knowing
  1428. >where to look for a particulat #define, variable, or function.
  1429. >So what I end up doing is uploading whole directories to my trusty Sparc
  1430. >and using the 'grep' command. I realize this is wrong on a very basic level
  1431. >and so what I want to ask is, does anyone know of an MPW Tool that duplicates
  1432. >the functionality of 'grep'?
  1433. >I could write one myself, all it would have to do is look through .c and .h
  1434. >files for a text pattern, but I would prefer it if I didn't have to.
  1435. >
  1436. >So, has anyone out there implemented 'grep'??
  1437. >
  1438. >- Dan
  1439. >
  1440.  
  1441.  
  1442. If you are working in MPW, there are tools you can use to accomplish the
  1443. same effect (though it's not as nice as grep IMHO).  The "files" tool
  1444. will list all the files in the specified directory, while the "search"
  1445. tool will search all the given files for the specified pattern.
  1446.  
  1447. In my worksheet, I have the following line marked as "Search in includes":
  1448.  
  1449. search -s /Gestalt/ `files -o -f -t TEXT "{mpw}"Interfaces:CIncludes`
  1450.  
  1451. This will search through all the MPW C header files for the given pattern.
  1452. In this case, it is searching for Gestalt.  To search for something else,
  1453. just change what's inside the '/' delimiters.  To search a different
  1454. directory, replace the "{mpw}"Interfaces:Cincludes with the directory
  1455. of your choice.  You can also specify the -r option to the files tool,
  1456. which will make the search recursively descend into subdirectories.
  1457.  
  1458. Hope that helps.
  1459.  
  1460. -Jon
  1461.  
  1462. +++++++++++++++++++++++++++
  1463.  
  1464. >From timothys@hood.uucp (Timothy Sherburne)
  1465. Date: 17 Aug 94 16:37:32 GMT
  1466. Organization: University of Portland
  1467.  
  1468. Bruce@hoult.actrix.gen.nz (Bruce Hoult) writes:
  1469.  
  1470. >zorro@cats.ucsc.edu (zorro) writes:
  1471. >> Constantly I find myself in the situation that Dina described... not knowing
  1472. >> where to look for a particulat #define, variable, or function.
  1473. >> So what I end up doing is uploading whole directories to my trusty Sparc
  1474. >> and using the 'grep' command. I realize this is wrong on a very basic level
  1475. >> and so what I want to ask is, does anyone know of an MPW Tool that duplicates
  1476. >> the functionality of 'grep'?
  1477. >> I could write one myself, all it would have to do is look through .c and .h
  1478. >> files for a text pattern, but I would prefer it if I didn't have to.
  1479.  
  1480. >What's wrong with "search"?  Name too obscure, or something?
  1481.  
  1482. >   search CloseWindow "{cincludes}"≈.h
  1483.  
  1484. >-- Bruce
  1485.  
  1486. All these suggestions to use the "search" tool are fine, but you can also install the "poptag" tool (found on the May '94 Tool Chest CD, but I couldn't find it on ETO 15 :(
  1487.  
  1488. It works like this:  highlight some function name, etc. and type cmd-P.  The definition will be given.
  1489.  
  1490. Works well IF you've got some extra space on your HD and the time to install it.
  1491.  
  1492. t
  1493. -- 
  1494.   | Timothy Sherburne                    |               Software Engineer |
  1495.   | Internet:  timothys@uofport.edu      |       Prometheus Products, Inc. |
  1496.   | AppleLink: D6164@applelink.apple.com |                  1-800-477-3473 |
  1497. *All comments are my own and in no way represent those of Prometheus Products*
  1498.  
  1499. +++++++++++++++++++++++++++
  1500.  
  1501. >From sw@network-analysis-ltd.co.uk (Sak Wathanasin)
  1502. Date: Thu, 18 Aug 94 10:35:34 BST
  1503. Organization: Network Analysis Ltd
  1504.  
  1505.  
  1506. In article <1994Aug17.075722.17513@adobe.com> (comp.sys.mac.programmer), zstern@adobe.com (Zalman Stern) writes:
  1507.  
  1508. > There is a port of the GNU grep command to MPW. I picked it up off  
  1509. > ftp.apple.com a year or two ago. Its faster and has more functionality than  
  1510. > search. The Mac is still relatively slow at this sort of thing compared to a  
  1511. > decent UNIX box though.
  1512.  
  1513. There's also "agrep" which is very fast; can't remember where I got
  1514. this from, but I can post to macgifts if people want it. Unfortunately,
  1515. it doesn't generate MPW-executable output like "Search", but it's dead
  1516. useful just for seeing which header file contains which definition.
  1517.  
  1518.  
  1519. Sak Wathanasin
  1520. Network Analysis Limited
  1521. 178 Wainbody Ave South, Coventry CV3 6BX, UK
  1522.  
  1523. Internet: sw@network-analysis-ltd.co.uk 
  1524. uucp:     ...!uknet!nan!sw                       AppleLink: NAN.LTD
  1525. Phone: (+44) 203 419996 Mobile:(+44) 850 587411  Fax: (+44) 203 690690
  1526.  
  1527. +++++++++++++++++++++++++++
  1528.  
  1529. >From lsr@taligent.com (Larry Rosenstein)
  1530. Date: Fri, 19 Aug 1994 17:30:55 GMT
  1531. Organization: Taligent, Inc.
  1532.  
  1533. In article <D2150050.7hqfm8@nan.network-analysis-ltd.co.uk>,
  1534. sw@network-analysis-ltd.co.uk wrote:
  1535.  
  1536. > There's also "agrep" which is very fast; can't remember where I got
  1537. > this from, but I can post to macgifts if people want it. Unfortunately,
  1538.  
  1539. If it's the same one I'm thinking of, then this is a fast string searcher
  1540. that allows for errors in the text (ie, it's more of a fuzzy match).  The
  1541. information I have says the source is available at
  1542. ftp://cs.arizona.edu/agrep/.
  1543.  
  1544. -- 
  1545. Larry Rosenstein
  1546. Taligent, Inc.
  1547.  
  1548. lsr@taligent.com
  1549.  
  1550. +++++++++++++++++++++++++++
  1551.  
  1552. >From hammett@sbsu1.auckland.ac.nz (Tim Hammett)
  1553. Date: 20 Aug 1994 23:25:41 GMT
  1554. Organization: University of Auckland
  1555.  
  1556. becker@Xenon.Stanford.EDU (Denizen of the Deep) writes:
  1557. >search -s /Gestalt/ `files -o -f -t TEXT "{mpw}"Interfaces:CIncludes`
  1558.  
  1559. Why not use:
  1560.  
  1561. search -s /Gestalt/ "{CIncludes}=.h"
  1562.  
  1563. (where = is option-x, i.e. the squiggly equals sign)
  1564.  
  1565. --
  1566. Tim Hammett, School of Biological Sciences, Auckland University, New Zealand.
  1567. t.hammett@auckland.ac.nz   Phone: +64-9-373-7599 x7298    FAX: +64-9-373-7416
  1568.  
  1569. +++++++++++++++++++++++++++
  1570.  
  1571. >From rollin@newton.apple.com (Keith Rollin)
  1572. Date: Wed, 24 Aug 1994 13:38:37 -0800
  1573. Organization: Apple ][ -> Mac -> Taligent -> Newton -> Windows?
  1574.  
  1575. In article <32te9f$goj@Times.Stanford.EDU>, becker@Xenon.Stanford.EDU
  1576. (Denizen of the Deep) wrote:
  1577.  
  1578. >
  1579. >If you are working in MPW, there are tools you can use to accomplish the
  1580. >same effect (though it's not as nice as grep IMHO).
  1581.  
  1582.  
  1583. I have a question for you, Jon: What does "grep" do that makes it so much
  1584. nicer than "search"?
  1585.  
  1586.  
  1587. >The "files" tool
  1588. >will list all the files in the specified directory, while the "search"
  1589. >tool will search all the given files for the specified pattern.
  1590. >
  1591. >In my worksheet, I have the following line marked as "Search in includes":
  1592. >
  1593. >search -s /Gestalt/ `files -o -f -t TEXT "{mpw}"Interfaces:CIncludes`
  1594. >
  1595. >This will search through all the MPW C header files for the given pattern.
  1596. >In this case, it is searching for Gestalt.  To search for something else,
  1597. >just change what's inside the '/' delimiters.  To search a different
  1598. >directory, replace the "{mpw}"Interfaces:Cincludes with the directory
  1599. >of your choice.  You can also specify the -r option to the files tool,
  1600. >which will make the search recursively descend into subdirectories.
  1601.  
  1602.  
  1603. Geeze, you make it look so difficult. I simply use:
  1604.  
  1605. search Gestalt "{CIncludes}"<opt-x>
  1606.  
  1607. Actually, I fibbed. I never do that. I just select the item in my Edit
  1608. menu that lets me search a common directory. In my UserStarup*Keith file,
  1609. I have:
  1610.  
  1611.     Set FabFolders "`quote <opt-d>
  1612.                     '{CIncludes}' <opt-d>
  1613.                     '{PInterfaces}' <opt-d>
  1614.                     '{AIncludes}' <opt-d>
  1615.                     '{RIncludes}' <opt-d>
  1616.                     '{MACPlusIncludes}' <opt-d>
  1617.                     '{MALibraries}' <opt-d>
  1618.                     '{MPWCustom}Scripts:' <opt-d>
  1619.                     '{MPW}Scripts:' <opt-d>
  1620.                     `"
  1621.  
  1622.     For f in {FabFolders}
  1623.         AddMenu "Find" "Search in {f}" "SearchIn <opt-d>"{f}<opt-d>" <opt-d>
  1624.             <opt-w><opt-w> <opt-d>"<opt-d>{WorkSheet<opt-d>}<opt-d>""
  1625.     End
  1626.  
  1627.  
  1628. "SearchIn" is the following script:
  1629.  
  1630.     Set Expr "`Request 'Enter regular expression' || Echo ''`"
  1631.     Exit If "{Expr}" == ""
  1632.     open "{WorkSheet}"
  1633.     if "{expr}" =~ /[a-z0-9]+/
  1634.         Search "{Expr}" "{1}" <opt-x>
  1635.     else
  1636.         Search /{Expr}/ "{1}" <opt-x>
  1637.     end
  1638.  
  1639. - --------------------------------------------------------------------------
  1640. Keith Rollin --- Phantom Programmer --- Apple Computer, Inc. --- Team Newton
  1641.  
  1642. +++++++++++++++++++++++++++
  1643.  
  1644. >From rollin@newton.apple.com (Keith Rollin)
  1645. Date: Thu, 25 Aug 1994 16:06:09 -0800
  1646. Organization: Apple ][ -> Mac -> Taligent -> Newton -> Windows?
  1647.  
  1648. In article <D2150050.7hqfm8@nan.network-analysis-ltd.co.uk>,
  1649. sw@network-analysis-ltd.co.uk wrote:
  1650.  
  1651. >In article <1994Aug17.075722.17513@adobe.com> (comp.sys.mac.programmer),
  1652. zstern@adobe.com (Zalman Stern) writes:
  1653. >
  1654. >> There is a port of the GNU grep command to MPW. I picked it up off  
  1655. >> ftp.apple.com a year or two ago. Its faster and has more functionality than  
  1656. >> search. The Mac is still relatively slow at this sort of thing compared
  1657. to a  
  1658. >> decent UNIX box though.
  1659. >
  1660. >There's also "agrep" which is very fast; can't remember where I got
  1661. >this from, but I can post to macgifts if people want it. Unfortunately,
  1662. >it doesn't generate MPW-executable output like "Search", but it's dead
  1663. >useful just for seeing which header file contains which definition.
  1664.  
  1665. I got a copy, dated Jan 1992, from cs.arizona.edu as agrep/agrep-2.04.tar.
  1666. Comes with source. I haven't tried it though.
  1667.  
  1668. - --------------------------------------------------------------------------
  1669. Keith Rollin --- Phantom Programmer --- Apple Computer, Inc. --- Team Newton
  1670.  
  1671. +++++++++++++++++++++++++++
  1672.  
  1673. >From rollin@newton.apple.com (Keith Rollin)
  1674. Date: Sun, 28 Aug 1994 18:21:13 -0800
  1675. Organization: Apple ][ -> Mac -> Taligent -> Newton -> Windows?
  1676.  
  1677. In article <3363dl$sil@ccu2.auckland.ac.nz>, hammett@sbsu1.auckland.ac.nz
  1678. (Tim Hammett) wrote:
  1679.  
  1680. >becker@Xenon.Stanford.EDU (Denizen of the Deep) writes:
  1681. >>search -s /Gestalt/ `files -o -f -t TEXT "{mpw}"Interfaces:CIncludes`
  1682. >
  1683. >Why not use:
  1684. >
  1685. >search -s /Gestalt/ "{CIncludes}=.h"
  1686. >
  1687. >(where = is option-x, i.e. the squiggly equals sign)
  1688.  
  1689.  
  1690. Using the following is much faster:
  1691.  
  1692. search -s Gestalt "{CIncludes}=.h"
  1693.  
  1694. The reason for this is that delimiting the search string with slashes
  1695. tells the Shell to perform a regular expression search. But the Shell can
  1696. also perform faster searches using a Boyer-Moore algorithm when it thinks
  1697. it's OK. Right now,  the only way it can tell this is when you feed it a
  1698. straight string. It would be nice if the searching routines would look in
  1699. the slashes and determine if it can use a Boyer-Moore search, but that's
  1700. not the way it works right now.
  1701.  
  1702. - --------------------------------------------------------------------------
  1703. Keith Rollin --- Phantom Programmer --- Apple Computer, Inc. --- Team Newton
  1704.  
  1705. ---------------------------
  1706.  
  1707. >From rmartin@luddites.tiac.net (Rich Martin)
  1708. Subject: Ticks (was: Clover+. interrupt?)
  1709. Date: Mon, 29 Aug 1994 14:58:16 -0500
  1710. Organization: Luddite Softwerks
  1711.  
  1712. PMJI, but this Ticks thing still haunts me. A project I worked on recently
  1713. was real-time intensive, and I assumed that Ticks would be incremented
  1714. every 1/60th second. IM told me that this was not guaranteed to happen
  1715. every time, but my assumption was that I would get no *more* than 60 ticks
  1716. in a second. All my time measurements went haywire. After much hair
  1717. pulling, we did some empirical tests and discovered that we were getting
  1718. something like 3605 ticks per minute. Yow! Slightly more than 60 ticks per
  1719. second! Over the course of 30 minutes, my program behaved as though it
  1720. were late when it actually was not. Once we accounted for this unexpected
  1721. Tick rate, timing improved sufficiently. Comments?
  1722. -- 
  1723. ____________________________________________________________________
  1724. http://www.mps.ohio-state.edu/cgi-bin/hpp?RichMartin.html |   Not   |
  1725. __________________________________________________________| Insane! |
  1726.       It's Easy to be Easy when You're Easy...            |_________|
  1727.  
  1728. +++++++++++++++++++++++++++
  1729.  
  1730. >From michael.martz@aldus.com (Michael Martz)
  1731. Date: 29 Aug 1994 20:41:40 GMT
  1732. Organization: Aldus Corporation, Seattle, WA USA
  1733.  
  1734. I had the very same thing happen to me a while ago. I set up code using
  1735. the time manager to count the number of ticks per second expecting to
  1736. find 55-60. When it turned out that I was getting 60+, I double checked
  1737. everything and then compared it to an external timing source. I
  1738. concluded that IM was incorrect.
  1739.  
  1740. I don't know why this occurs, but rest assured you are sane. For
  1741. periods around 30 minutes you really should be using the new Time
  1742. Manger rather than Ticks.
  1743.  
  1744. _______________________________________________________________________
  1745. Michael Martz           michael.martz@aldus.com             Aldus Corp.
  1746.  
  1747. +++++++++++++++++++++++++++
  1748.  
  1749. >From spector@bach.seattleu.edu (Mitchell S. Spector)
  1750. Date: 30 Aug 1994 09:24:58 -0700
  1751. Organization: Seattle University, Seattle, Washington, U.S.A.
  1752.  
  1753. In article <rmartin-2908941458160001@luddites.tiac.net>,
  1754. Rich Martin <rmartin@luddites.tiac.net> wrote:
  1755. >PMJI, but this Ticks thing still haunts me. A project I worked on recently
  1756. >was real-time intensive, and I assumed that Ticks would be incremented
  1757. >every 1/60th second. IM told me that this was not guaranteed to happen
  1758. >every time, but my assumption was that I would get no *more* than 60 ticks
  1759. >in a second. All my time measurements went haywire. After much hair
  1760. >pulling, we did some empirical tests and discovered that we were getting
  1761. >something like 3605 ticks per minute. Yow! Slightly more than 60 ticks per
  1762. >second! Over the course of 30 minutes, my program behaved as though it
  1763. >were late when it actually was not. Once we accounted for this unexpected
  1764. >Tick rate, timing improved sufficiently. Comments?
  1765.  
  1766.    I know IM says in various places that a tick is 1/60 of a second.
  1767. But, according to the discussion of the video interface in IM vol. III,
  1768. the vertical scan rate of the original Macintosh monitor was 60.15 Hz,
  1769. not 60 Hz.  I presume this implies that VBL interrupts were generated
  1770. every 1/60.15 sec, a little faster than 1/60 sec.  This would mean that
  1771. there were 3609 ticks per minute.
  1772.  
  1773.    I have no idea if Apple has maintained compatibility with the
  1774. original Mac to the point of generating VBL interrupts at exactly
  1775. the same frequency as on the original Mac.  But I take all this to
  1776. mean that Apple does not guarantee the exact frequency of the VBL
  1777. interrupt, and that no program should use ticks for exact timing.
  1778. The Time Manager should be used for that.
  1779.  
  1780. >-- 
  1781. >____________________________________________________________________
  1782. >http://www.mps.ohio-state.edu/cgi-bin/hpp?RichMartin.html |   Not   |
  1783. >__________________________________________________________| Insane! |
  1784. >      It's Easy to be Easy when You're Easy...            |_________|
  1785.  
  1786. --
  1787. Mitchell Spector
  1788. Dept. of Computer Science and Software Engineering
  1789. Seattle University
  1790. E-mail: spector@seattleu.edu
  1791.  
  1792.  
  1793. +++++++++++++++++++++++++++
  1794.  
  1795. >From h+@nada.kth.se (Jon W{tte)
  1796. Date: Tue, 30 Aug 1994 20:33:13 +0200
  1797. Organization: Royal Institute of Something or other
  1798.  
  1799. In article <rmartin-2908941458160001@luddites.tiac.net>,
  1800. rmartin@luddites.tiac.net (Rich Martin) wrote:
  1801.  
  1802. >were late when it actually was not. Once we accounted for this unexpected
  1803. >Tick rate, timing improved sufficiently. Comments?
  1804.  
  1805. Yeah, there are 60.15 ticks per second. This is documented.
  1806.  
  1807. What you should do is use the 
  1808. NewImprovedREALLYDriftFreeTimeManager to install a 
  1809. ReallyDriftFree TimeManager task that increments a variable. 
  1810. The plus side of this is that you get to set the interval of 
  1811. the "ticks"
  1812.  
  1813. Cheers,
  1814.  
  1815.                 / h+
  1816.  
  1817.  
  1818. --
  1819.   Jon W‰tte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden
  1820.  
  1821.   Reality exists only in your imagination.
  1822.  
  1823.  
  1824. +++++++++++++++++++++++++++
  1825.  
  1826. >From radixinc@aol.com (RadixInc)
  1827. Date: 30 Aug 1994 18:16:06 -0400
  1828. Organization: America Online, Inc. (1-800-827-6364)
  1829.  
  1830. In article <33vmgq$sqi@bach.seattleu.edu>, spector@bach.seattleu.edu
  1831. (Mitchell S. Spector) writes:
  1832.  
  1833. <<I have no idea if Apple has maintained compatibility with the
  1834. original Mac to the point of generating VBL interrupts at exactly
  1835. the same frequency as on the original Mac.>>
  1836.  
  1837. Apple has maintained compatibility; regardless of the actual monitor
  1838. frequency, a "VBL" interrupt is synthesized, supposedly at the original
  1839. 60.15/sec rate. As others have mentioned using the Ticks/VBL mechanism for
  1840. accurate timing is not advised, because (a) the frequency is not
  1841. guaranteed, and (b) VBL tasks (and updating Ticks) don't happen while
  1842. interrupts are disabled.
  1843.  
  1844. Gregory Jorgensen
  1845. Radix Consulting Inc.
  1846.  
  1847. ---------------------------
  1848.  
  1849. >From tfullert@bottom.magnus.acs.ohio-state.edu (tfullert)
  1850. Subject: What is the point of MPW?
  1851. Date: 13 Aug 1994 15:39:41 GMT
  1852. Organization: The Ohio State University
  1853.  
  1854. Hi:
  1855.  
  1856. I was given a copy of MPW 3.3 (not pirated, I was given all of the
  1857. materials in the huge box),and have the current shell from CodeWarrior.
  1858.  I am doing all of my own work on CodeWarrior and I want to devote some
  1859. energy to learning MPW.  What priority should I give this, though. 
  1860. Exactly what can I do with MPW which I cannot do with CodeWarrior or
  1861. SC++?
  1862.  
  1863. Thanks;
  1864.  
  1865. Tim
  1866.  
  1867. +++++++++++++++++++++++++++
  1868.  
  1869. >From nagle@netcom.com (John Nagle)
  1870. Date: Sat, 13 Aug 1994 20:06:23 GMT
  1871. Organization: NETCOM On-line Communication Services (408 261-4700 guest)
  1872.  
  1873. tfullert@bottom.magnus.acs.ohio-state.edu (tfullert) writes:
  1874. >I was given a copy of MPW 3.3 (not pirated, I was given all of the
  1875. >materials in the huge box),and have the current shell from CodeWarrior.
  1876. > I am doing all of my own work on CodeWarrior and I want to devote some
  1877. >energy to learning MPW.  What priority should I give this, though. 
  1878. >Exactly what can I do with MPW which I cannot do with CodeWarrior or
  1879. >SC++?
  1880.  
  1881.        The MPW compilers are so out-of-date that unless you have old
  1882. software developed under MPW you need to maintain, don't bother.
  1883.  
  1884.        MPW is basically a UNIX-like command line oriented environment,
  1885. under which you can run various UNIX-like tools.  It's useful if you
  1886. need to build UNIX-like tools to process data as part of your
  1887. program-building process. MPW dates from when the Mac could only run 
  1888. one program at a time, and it has its own hack for running "MPW tools" 
  1889. under its own shell.
  1890.  
  1891.                         John Nagle
  1892.  
  1893. +++++++++++++++++++++++++++
  1894.  
  1895. >From mclow@san_marcos.csusm.edu (Marshall Clow)
  1896. Date: Sat, 13 Aug 1994 13:53:09 -0800
  1897. Organization: Aladdin Systems
  1898.  
  1899. In article <32ipft$18t@charm.magnus.acs.ohio-state.edu>,
  1900. tfullert@bottom.magnus.acs.ohio-state.edu (tfullert) wrote:
  1901.  
  1902. > Hi:
  1903. > I was given a copy of MPW 3.3 (not pirated, I was given all of the
  1904. > materials in the huge box),and have the current shell from CodeWarrior.
  1905. >  I am doing all of my own work on CodeWarrior and I want to devote some
  1906. > energy to learning MPW.  What priority should I give this, though. 
  1907. > Exactly what can I do with MPW which I cannot do with CodeWarrior or
  1908. > SC++?
  1909.    Try this in CodeWarrior (or Think, for that matter). Build an
  1910. application containing 4 LDEFs, 2 MDEFs, 3 WDEFs, as well as 12 plug in
  1911. tools, putting the 'CODE' resources and the xDEF resources in a file of
  1912. type 'APPL', while each of the tools goes in a seperate file. Don't forget
  1913. to put the build date (and time) into the 'vers' resource so that testers
  1914. can tell exactily what they have. After you have built the application,
  1915. compress the resources in the application.
  1916.  
  1917. Oh yes, do this by choosing a single menu option.
  1918.  
  1919. -- 
  1920. Marshall Clow
  1921. Aladdin Systems
  1922. mclow@san_marcos.csusm.edu
  1923.  
  1924. +++++++++++++++++++++++++++
  1925.  
  1926. >From afcjlloyd@aol.com (AFC JLloyd)
  1927. Date: 13 Aug 1994 16:59:05 -0400
  1928. Organization: America Online, Inc. (1-800-827-6364)
  1929.  
  1930. In article <nagleCuHp6o.IsL@netcom.com>, nagle@netcom.com (John Nagle)
  1931. writes:
  1932.  
  1933. >tfullert@bottom.magnus.acs.ohio-state.edu (tfullert) writes:
  1934. >>I was given a copy of MPW 3.3 (not pirated, I was given all of the
  1935. >>materials in the huge box),and have the current shell from CodeWarrior.
  1936. >> I am doing all of my own work on CodeWarrior and I want to devote some
  1937. >>energy to learning MPW.  What priority should I give this, though. 
  1938. >>Exactly what can I do with MPW which I cannot do with CodeWarrior or
  1939. >>SC++?
  1940. >
  1941. >       The MPW compilers are so out-of-date that unless you have old
  1942. >software developed under MPW you need to maintain, don't bother.
  1943. >
  1944. >       MPW is basically a UNIX-like command line oriented environment,
  1945. >under which you can run various UNIX-like tools.  It's useful if you
  1946. >need to build UNIX-like tools to process data as part of your
  1947. >program-building process. MPW dates from when the Mac could only run 
  1948. >one program at a time, and it has its own hack for running "MPW tools" 
  1949. >under its own shell.
  1950.  
  1951. Although I agree a little with John Nagle's intent, I strongly disagree
  1952. with his message.  Although I use Think and CodeWarrior more than MPW, MPW
  1953. is still my preferred development environment when working on large
  1954. projects.  
  1955.  
  1956. The best thing about TPM and CodeWarrior is that they remove the need for
  1957. make files.  On small and medium sized projects, and even large projects
  1958. where only a single application is to be built, the ability to let the
  1959. environment deal with dependencies is a real blessing.
  1960.  
  1961. The worst thing about TPM and CodeWarrior is that remove the ability to
  1962. use custom make files.  On large projects where many loosely related
  1963. components must be built, the project-based environments are a pain. 
  1964. Maybe someday these enviroments will properly support subprojects or
  1965. makefiles, but until then, MPW is still superior for this kind of
  1966. development.
  1967.  
  1968. As to the MPW compilers being out of date, I suppose this is true if by
  1969. "MPW compilers" you mean Apple's C, Pascal, and CFront.  However, both
  1970. Symantec and Metrowerks have provided their compilers as MPW tools, and
  1971. the hybrid MrC available on ETO 15 looks like it may be a real winner
  1972. (I've only been using it for a couple days, so it's too soon for me to
  1973. say).
  1974.  
  1975. Jim Lloyd
  1976. afcjlloyd@aol.com
  1977.  
  1978.  
  1979. +++++++++++++++++++++++++++
  1980.  
  1981. >From hanrek@cts.com (Mark Hanrek)
  1982. Date: Sat, 13 Aug 1994 15:10:32 -0800
  1983. Organization: The Information Workshop
  1984.  
  1985. In article <32ipft$18t@charm.magnus.acs.ohio-state.edu>,
  1986. tfullert@bottom.magnus.acs.ohio-state.edu (tfullert) wrote:
  1987.  
  1988. > I was given a copy of MPW 3.3 (not pirated, I was given all of the
  1989. > materials in the huge box),and have the current shell from CodeWarrior.
  1990. > I am doing all of my own work on CodeWarrior and I want to devote some
  1991. > energy to learning MPW.  What priority should I give this, though. 
  1992. > Exactly what can I do with MPW which I cannot do with CodeWarrior or
  1993. > SC++?
  1994.  
  1995.  
  1996. Tim,
  1997.  
  1998. For one thing, you will have the privilege of compiling and easily playing
  1999. with example source code from Apple, which is quite often only available
  2000. in MPW format.
  2001.  
  2002. Apple is getting better at this, or perhaps it is because of the
  2003. individuals at Apple who realize that...
  2004.  
  2005.    "If you want programmers out there to move quickly, 
  2006.     don't make them jump through the hoop of having to 
  2007.     convert MPW source code to their environment."
  2008.  
  2009. ... and have graciously provided source code ready-to-compile for all the
  2010. big-three environments.
  2011.  
  2012. I am in the same situation as you are -- minus MPW.
  2013.  
  2014. Personally, I am really pissed, because I have Symantec C++, and the
  2015. PowerPC SDK, and I also have CodeWarrior 3.5, and that adds up to a good
  2016. chunk of change and a major investment of time.
  2017.  
  2018. For a while there, MPW was abandoned.
  2019.  
  2020. But now, I have been unable to participate as an OpenDoc early adopter, or
  2021. to even take advantage of the recent develop article on OSA -- which is
  2022. critical to my work -- just because I can't afford to purchase MPW, who's
  2023. price just went up to $450 the other day.
  2024.  
  2025. It makes my head spin.  I want to smash something.
  2026.  
  2027. I have always felt that all would-be Mac developers should be alerted that
  2028. it is not realistic to undertake developing software for the Macintosh
  2029. without having a minimum of $10,000 to spend on the minimum things you
  2030. need, and at least one year to write the simplest of programs (due to the
  2031. incredible wastes of time).
  2032.  
  2033. I wouldn't have then gone through all this anguish, and embarrassing
  2034. myself in front of so many people ( you know... investors, friends,
  2035. parents, c.s.m.p. ).
  2036.  
  2037. I can't blame anyone except myself.  I know that.  
  2038.  
  2039. Even so, the world can be a screwed up place to write Mac software in.
  2040.  
  2041. So much needed talent -- wasted.
  2042.  
  2043. <shaking head>
  2044.  
  2045.  
  2046. Mark Hanrek
  2047. The Information Workshop
  2048.  
  2049. - ---------------------------------------------------------
  2050. P.S.  Tim:  Keep it.  You'll need it.
  2051.  
  2052. +++++++++++++++++++++++++++
  2053.  
  2054. >From hanrek@cts.com (Mark Hanrek)
  2055. Date: Sat, 13 Aug 1994 16:03:09 -0800
  2056. Organization: The Information Workshop
  2057.  
  2058. In article <hanrek-1308941510320001@auke.cts.com>, hanrek@cts.com (Mark
  2059. Hanrek) wrote:
  2060.  
  2061. > ...can't afford to purchase MPW, who's price just went up to $450
  2062.  
  2063. oops.  After I went to check my facts, I realized that the $350 option
  2064. still remains.  
  2065.  
  2066. But I can save money by spending a hundred dollars more! :)
  2067.  
  2068.  
  2069. - ---------
  2070.  
  2071. A humorous aside...
  2072.  
  2073.  
  2074.   The rich get extra "quantity discounts".
  2075.   The poor get extra "late fees".
  2076.  
  2077.  
  2078. Crazy man, crazy.  :)
  2079.  
  2080.  
  2081. Mark Hanrek
  2082. The Information Workshop
  2083.  
  2084. +++++++++++++++++++++++++++
  2085.  
  2086. >From spencerl@crl.com (Spencer Low)
  2087. Date: Sat, 13 Aug 1994 20:15:26 -0800
  2088. Organization: LowTek Creations
  2089.  
  2090. In article <mclow-1308941353090001@lpm9.csusm.edu>,
  2091. mclow@san_marcos.csusm.edu (Marshall Clow) wrote:
  2092. >    Try this in CodeWarrior (or Think, for that matter). Build an
  2093. > application containing 4 LDEFs, 2 MDEFs, 3 WDEFs, as well as 12 plug in
  2094. > tools, putting the 'CODE' resources and the xDEF resources in a file of...
  2095. [more incredibly complex make stuff deleted :-]
  2096.  
  2097. Isn't this possible to do with ToolServer and some of the MPW tools? Or
  2098. does it get even more complex then?
  2099.  
  2100. (The worse I've had to do is to get AppleScript to talk to ToolServer to
  2101. Rez some files (with a special MPW/ToolServer script), open up my CW
  2102. project, link and make it, etc.)
  2103.  
  2104. Thanks,
  2105. Spencer
  2106. ________________________________________________________________________
  2107.   Spencer "MaxRAM" Low ------ LowTek Creations ----- spencerl@crl.com
  2108.  
  2109. +++++++++++++++++++++++++++
  2110.  
  2111. >From joseph@joebloe.maple-shade.nj.us (Joseph Nathan Hall)
  2112. Date: Sat, 13 Aug 94 22:20:46 MST
  2113. Organization: 5 Sigma Software
  2114.  
  2115.  
  2116. In article <nagleCuHp6o.IsL@netcom.com> (comp.sys.mac.programmer), nagle@netcom.com (John Nagle) writes:
  2117. ) tfullert@bottom.magnus.acs.ohio-state.edu (tfullert) writes:
  2118. ) >I was given a copy of MPW 3.3 (not pirated, I was given all of the
  2119. ) >materials in the huge box),and have the current shell from CodeWarrior.
  2120. ) > I am doing all of my own work on CodeWarrior and I want to devote some
  2121. ) >energy to learning MPW.  What priority should I give this, though. 
  2122. ) >Exactly what can I do with MPW which I cannot do with CodeWarrior or
  2123. ) >SC++?
  2124. )        The MPW compilers are so out-of-date that unless you have old
  2125. ) software developed under MPW you need to maintain, don't bother.
  2126. )        MPW is basically a UNIX-like command line oriented environment,
  2127. ) under which you can run various UNIX-like tools.  It's useful if you
  2128. ) need to build UNIX-like tools to process data as part of your
  2129. ) program-building process. MPW dates from when the Mac could only run 
  2130. ) one program at a time, and it has its own hack for running "MPW tools" 
  2131. ) under its own shell.
  2132.  
  2133. Yeah, it's a bummer when a tool dies, since it takes the shell with it.
  2134. Oh, well.
  2135.  
  2136. But anyway, yes, the compilers are slow and have some inappropriately
  2137. glib error messages that become less funny at 4 in the morning.  However,
  2138. there is no equivalent to MPW make in either TPM or CW.  Applescripts
  2139. are a somewhat awkward alternative, I guess, but for those of us who have
  2140. special needs (yacc-generated sources, or perhaps some inputs generated
  2141. by a perl script), MPW is basically the only way to automate the building 
  2142. of complex projects.  I think that you will find many commercial developers 
  2143. using MPW to build auxiliary stuff even if they don't use it for compiles 
  2144. in general.
  2145.  
  2146. Also, MPW gives you input redirection and piping for tools, which is handy 
  2147. and not available otherwise.
  2148.  
  2149. The word from Apple, which I will take under advisement, is that the
  2150. compilers are scheduled for a rev for speed later this year.
  2151.  
  2152. =============== O Fortuna, velut Luna, statu variabilis ===============
  2153. uunet!joebloe!joseph   (602) 732-2549 day   joseph%joebloe@uunet.uu.net
  2154. 1400 N Alma School                #163               Chandler, AZ 85224
  2155. Copyright 1994 by Joseph N. Hall.            Commercial use prohibited.
  2156.     "The division-WINNING Phillies!" -- Section 236, Row 08, Seat 03
  2157.                       (well, those were the days)
  2158.  
  2159. +++++++++++++++++++++++++++
  2160.  
  2161. >From wysocki@netcom.com (Chris Wysocki)
  2162. Date: Sun, 14 Aug 1994 07:41:37 GMT
  2163. Organization: NETCOM On-line Communication Services (408 261-4700 guest)
  2164.  
  2165. In article <hanrek-1308941510320001@auke.cts.com>,
  2166. Mark Hanrek <hanrek@cts.com> wrote:
  2167.  
  2168. >I have always felt that all would-be Mac developers should be alerted that
  2169. >it is not realistic to undertake developing software for the Macintosh
  2170. >without having a minimum of $10,000 to spend on the minimum things you
  2171. >need, and at least one year to write the simplest of programs (due to the
  2172. >incredible wastes of time).
  2173.  
  2174. Mark, would you care to enlighten all of us as to exactly how you
  2175. arrived at this $10,000 figure?  I personally have been programming
  2176. the Macintosh since 1985, and over the course of these nine years I
  2177. have not spent a combined $10k on all the development tools, books,
  2178. documentation and other resources that I have purchased, and I own a
  2179. fairly complete library of Macintosh development tools.  Today anyone
  2180. can go out and buy Code Warrior Bronze for $99, THINK Reference for
  2181. $50, the new Inside Macintosh CD for $99, a subscription to develop
  2182. for $30, and a few good tutorial books for $200, and they'll have an
  2183. excellent set of tools for learning how to program the Macintosh, all
  2184. for less than $500.  One certainly could easily spend far more than
  2185. this, but saying that $10k is needed to start programming the
  2186. Macintosh is akin to saying that one must purchase a $90,000 BMW 850iL
  2187. in order to learn how to drive a car.
  2188.  
  2189. Chris.
  2190.  
  2191.  
  2192. +++++++++++++++++++++++++++
  2193.  
  2194. >From sw@network-analysis-ltd.co.uk (Sak Wathanasin)
  2195. Date: Sun, 14 Aug 94 11:45:04 BST
  2196. Organization: Network Analysis Ltd
  2197.  
  2198.  
  2199. In article <mclow-1308941353090001@lpm9.csusm.edu> (comp.sys.mac.programmer), mclow@san_marcos.csusm.edu (Marshall Clow) writes:
  2200.  
  2201. >    Try this in CodeWarrior (or Think, for that matter). Build an
  2202. > application containing 4 LDEFs, 2 MDEFs, 3 WDEFs, as well as 12 plug in
  2203. > tools, putting the 'CODE' resources and the xDEF resources in a file of
  2204. > type 'APPL', while each of the tools goes in a seperate file. Don't forget
  2205. > to put the build date (and time) into the 'vers' resource so that testers
  2206. > can tell exactily what they have. After you have built the application,
  2207. > compress the resources in the application.
  2208. > Oh yes, do this by choosing a single menu option.
  2209.  
  2210. Never mind that - just building a fat PPC/68K application with CW is a
  2211. pain in the nether regions. With CW you have to maintain 2 separate
  2212. projects, one for 68K, one for PPC. With MPW, I have 1 makefile to look
  2213. after.
  2214.  
  2215. Another thing that gets me with the CW/Think approach is that you must
  2216. include all of the srcs files for TCL, MacApp, PowerPlant, whatever
  2217. into your project if you want symbolic debugging of the libs. That
  2218. means a copy of the lib (with symbols) for every project that uses the
  2219. class lib. OK, so 1 GB disks are ten a penny these days. But when I get
  2220. a new release of TCL, MacApp, or whatever, it means recompiling every
  2221. TC/CW project that uses these libs. So if you have 10 projects that
  2222. use, say, MacApp, that means recompiling MacApp 10 times. With MPW, I
  2223. recompile the class lib once, build a library, then relink; at most I
  2224. only have to recompile my srcs (because of header changes). Much more
  2225. civilized.
  2226.  
  2227. Luckily, from CW 3.5 on, I have the best of both worlds.
  2228.  
  2229. Sak Wathanasin
  2230. Network Analysis Limited
  2231. 178 Wainbody Ave South, Coventry CV3 6BX, UK
  2232.  
  2233. Internet: sw@network-analysis-ltd.co.uk 
  2234. uucp:     ...!uknet!nan!sw                       AppleLink: NAN.LTD
  2235. Phone: (+44) 203 419996 Mobile:(+44) 850 587411  Fax: (+44) 203 690690
  2236.  
  2237. +++++++++++++++++++++++++++
  2238.  
  2239. >From partingt@fwi.uva.nl (Vincent Partington)
  2240. Date: 14 Aug 1994 15:20:23 GMT
  2241. Organization: FWI, University of Amsterdam
  2242.  
  2243. spencerl@crl.com (Spencer Low) writes:
  2244.  
  2245. >Isn't this possible to do with ToolServer and some of the MPW tools? Or
  2246. >does it get even more complex then?
  2247.  
  2248. I've written a small MPW Tool that can send a "Make Project" event to the
  2249. CodeWarrior environment. I use a makefile for stuff that needs to be built
  2250. by MPW Tools (Rez, Flex, Bison) and a CW project for the C code.
  2251. I type the following in the ToolServer window to have everything updated
  2252. automatically:
  2253. Make >__commands
  2254. __commands
  2255. delete __commands
  2256. MPWMake
  2257.  
  2258. O yeah, the tool doesn't need AppleScript to do this. Funnily enough I got CW4
  2259. yesterday and it contains some sample code to send AppleEvents to the CW
  2260. environment.
  2261. Anyway the source can be gotten by fingering partingt@gene.fwi.uva.nl.
  2262.  
  2263. Vincent.
  2264. -- 
  2265. appel peer banaan baksteen           ||| The Fingerware Project:
  2266. schelp zon zand rolstoel             ||| Put your code snippets in your .plan!
  2267. groen wit geel flatgebouw            ||| If you want to know more
  2268. boer postbode bouwvakker roos        ||| finger partingt@gene.fwi.uva.nl
  2269.  
  2270. +++++++++++++++++++++++++++
  2271.  
  2272. >From nick+@pitt.edu ( nick.c )
  2273. Date: Sun, 14 Aug 94 18:19:05 GMT
  2274. Organization: The Pitt, Chemistry
  2275.  
  2276. In Article <hanrek-1308941510320001@auke.cts.com>, hanrek@cts.com (Mark
  2277. Hanrek) wrote:
  2278.  
  2279. >Personally, I am really pissed, because I have Symantec C++, and the
  2280. >PowerPC SDK, and I also have CodeWarrior 3.5, and that adds up to a good
  2281. >chunk of change and a major investment of time.
  2282. >
  2283. >For a while there, MPW was abandoned.
  2284. >
  2285. >But now, I have been unable to participate as an OpenDoc early adopter, or
  2286. >to even take advantage of the recent develop article on OSA -- which is
  2287. >critical to my work -- just because I can't afford to purchase MPW, who's
  2288. >price just went up to $450 the other day.
  2289.  
  2290.  
  2291.     Not sure if this helps (you might be talking about the Apple
  2292.       compilers), but there is a fully configured version of the MPW
  2293.       shell for use with CW on CW4 - I think it was there for 3.5 too.
  2294.  
  2295.  
  2296.   
  2297.  
  2298.      Interet: nick@pitt.edu         _/   _/  _/  _/_/_/   _/   _/  
  2299.       eWorld: nick                 _/_/ _/  _/  _/   _/  _/_/_/    
  2300.          CIS: 71232,766           _/ _/_/  _/  _/       _/ _/      
  2301.                                  _/   _/  _/   _/_/_/  _/   _/     
  2302.     
  2303.            "Science is nothing but perception" - Plato
  2304.  
  2305.  
  2306. +++++++++++++++++++++++++++
  2307.  
  2308. >From Ken Prehoda <kenp@nmrfam.wisc.edu>
  2309. Date: 14 Aug 1994 21:29:19 GMT
  2310. Organization: Univ of Wisc-Madison
  2311.  
  2312. In article <nick+.1127275985H@usenet.pitt.edu>
  2313. nick.c, nick+@pitt.edu writes:
  2314. >    Not sure if this helps (you might be talking about the Apple
  2315. >      compilers), but there is a fully configured version of the MPW
  2316. >      shell for use with CW on CW4 - I think it was there for 3.5 too.
  2317.  
  2318. I think Mark was talking about the MPW compilers, since he said he
  2319. has codewarrior AND the PPC SDK, both of which contain the MPW 3.3
  2320. shell.
  2321.  
  2322. Currently, MPW C++ is pretty much required to do build opendoc part
  2323. editors.  I, and I'm sure many others, are waiting for the opendoc
  2324. beta (that uses SOM instead of ASLM) so we can use MW C++ (or
  2325. Symantec).
  2326.  
  2327. However, there is a folder on the OpenDoc A6 CD for building opendoc
  2328. with codewarrior which can get you a long way until the beta arrives.
  2329.  
  2330. -Ken Prehoda
  2331. kenp@nmrfam.wisc.edu
  2332.  
  2333. +++++++++++++++++++++++++++
  2334.  
  2335. >From Gavriel State <grstate@metrowerks.ca>
  2336. Date: 14 Aug 1994 18:36:49 GMT
  2337. Organization: Metrowerks Inc.
  2338.  
  2339. In article <D2150050.77d207@nan.network-analysis-ltd.co.uk> Sak Wathanasin, 
  2340. sw@network-analysis-ltd.co.uk writes:
  2341. > Another thing that gets me with the CW/Think approach is that you must
  2342. > include all of the srcs files for TCL, MacApp, PowerPlant, whatever
  2343. > into your project if you want symbolic debugging of the libs. That
  2344.  
  2345. In CW4 you can debug PPC shared libraries in source.  Just build MacApp, 
  2346. Powerplant, or whatever as a shared library, include it in your project, 
  2347. and go.  
  2348.  
  2349. --
  2350.  Gavriel State | 4A Systems Design Engineering/Economics | Univ. of Waterloo
  2351. - ---------------------------------------------------------------------------
  2352. Email: grstate@metrowerks.ca    | "Sentence fragment.  Another.  Good device.
  2353. - ------------------------------|   Will be used more later." - This is the
  2354.  Metrowerks CodeWarrior Pascal  |   title of the story, which is also found
  2355. Co-Op Engineering Student Person|      several times in the story itself.
  2356.  
  2357. +++++++++++++++++++++++++++
  2358.  
  2359. >From chrism@col.hp.com (Chris Magnuson)
  2360. Date: 15 Aug 1994 04:07:20 GMT
  2361. Organization: HP Colorado Springs Division
  2362.  
  2363. Chris Wysocki (wysocki@netcom.com) wrote:
  2364. : In article <hanrek-1308941510320001@auke.cts.com>,
  2365. : Mark Hanrek <hanrek@cts.com> wrote:
  2366.  
  2367. <snip snip>
  2368. : Mark, would you care to enlighten all of us as to exactly how you
  2369. : arrived at this $10,000 figure?  I personally have been programming
  2370. : the Macintosh since 1985, and over the course of these nine years I
  2371. : have not spent a combined $10k on all the development tools, books,
  2372. : documentation and other resources that I have purchased, and I own a
  2373. : fairly complete library of Macintosh development tools.  Today anyone
  2374. : can go out and buy Code Warrior Bronze for $99, THINK Reference for
  2375. : $50, the new Inside Macintosh CD for $99, a subscription to develop
  2376. : for $30, and a few good tutorial books for $200, and they'll have an
  2377. : excellent set of tools for learning how to program the Macintosh, all
  2378. : for less than $500.  One certainly could easily spend far more than
  2379. : this, but saying that $10k is needed to start programming the
  2380. : Macintosh is akin to saying that one must purchase a $90,000 BMW 850iL
  2381. : in order to learn how to drive a car.
  2382.  
  2383.   Well, you forgot to buy a Mac for one thing. :)
  2384.  
  2385.   Chris Magnuson
  2386.   chrism@col.hp.com
  2387.  
  2388. +++++++++++++++++++++++++++
  2389.  
  2390. >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!")
  2391. Date: Mon, 15 Aug 1994 14:30:46 +0800
  2392. Organization: Department of Computer Science, The University of Western Australia
  2393.  
  2394. In article <01050166.75ttt1@joebloe.maple-shade.nj.us>,
  2395. joseph@joebloe.maple-shade.nj.us wrote:
  2396.  
  2397. >Yeah, it's a bummer when a tool dies, since it takes the shell with it.
  2398. >Oh, well.
  2399.  
  2400. The tool has to die pretty badly for "g sysrecover" to fail.
  2401. -- 
  2402. Quinn "The Eskimo!"      <quinn@cs.uwa.edu.au>     "Support HAVOC!"
  2403. Department of Computer Science, The University of Western Australia
  2404.  
  2405. +++++++++++++++++++++++++++
  2406.  
  2407. >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!")
  2408. Date: Mon, 15 Aug 1994 14:33:32 +0800
  2409. Organization: Department of Computer Science, The University of Western Australia
  2410.  
  2411. In article <spencerl-130894201526@DialupNewsWatcher>, spencerl@crl.com
  2412. (Spencer Low) wrote:
  2413.  
  2414. >Isn't this possible to do with ToolServer and some of the MPW tools? Or
  2415. >does it get even more complex then?
  2416.  
  2417. I've built things in MPW that would make your hair curl.  Specifically
  2418. trying to hack MW or TPM to build something as complicated as LabMaster
  2419. would have been defeating the point of these environments.  Use the right
  2420. tools for the job.  If you're building an application then using MW or
  2421. TPM.  If you're building something hideous then MPW is your friend.
  2422.  
  2423. Besides [warning, holy way bait!] MPW's editor is *sooo* m                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 clumps.
  2424. :)
  2425.  
  2426. Still trying...
  2427.  
  2428. Mark Hanrek
  2429.  
  2430. +++++++++++++++++++++++++++
  2431.  
  2432. >From mclow@san_marcos.csusm.edu (Marshall Clow)
  2433. Date: Mon, 15 Aug 1994 10:14:05 -0800
  2434. Organization: Aladdin Systems
  2435.  
  2436. In article <tree-1508940738330001@155.64.60.63>, tree@bedford.symantec.com
  2437. (Tom Emerson) wrote:
  2438.  
  2439. > In article <quinn-1508941433320001@edu-dynamic1.educ.ecel.uwa.edu.au>,
  2440. > quinn@cs.uwa.edu.au (Quinn "The Eskimo!") wrote:
  2441. > > Besides [warning, holy way bait!] MPW's editor is *sooo* much better than
  2442. > > any other editor on the Mac.
  2443. > So, what features of the MPW editor do you prefer over those provided by
  2444. > any other editor?
  2445.  
  2446. Tom --
  2447.  
  2448.    My _favorite_ MPW editor feature is the "double click on open
  2449. paren/brace/bracket/slash/quote and select everything up to the matching
  2450. symbol. (Also works with 2x-clicking on the closing symbol. If you hold
  2451. the mouse button down after the second click, you can move the cursor
  2452. around and see the selection change to show differing "matches"
  2453.  
  2454. MUCH, much better than the "Balance" command in Think.
  2455.  
  2456. -- Marshall
  2457. [ Who's trying to turn an potential flame war into a rational discussion. ]
  2458.  
  2459. -- 
  2460. Marshall Clow
  2461. Aladdin Systems
  2462. mclow@san_marcos.csusm.edu
  2463.  
  2464. +++++++++++++++++++++++++++
  2465.  
  2466. >From kenp@tuli (Kenneth Prehoda)
  2467. Date: 15 Aug 1994 18:31:25 GMT
  2468. Organization: Division of Information Technology
  2469.  
  2470. Mark Hanrek (hanrek@cts.com) wrote:
  2471. : Thanks, Ken, for clarifying that for me.  And thanks for the reference to
  2472. : that folder!
  2473.  
  2474. : I quadruple-checked for anything to do with CodeWarrior on the A6 CD, and
  2475. : found a read-me that referred to a folder that does not exist, at least on
  2476. : the WWDC version of OpenDoc A6.
  2477.  
  2478. : So, is it the case that this folder does exist on another version of the
  2479. : OpenDoc A6 release?  I looked on eWorld, but those files come in clumps.
  2480. : :)
  2481.  
  2482. : Still trying...
  2483.  
  2484. : Mark Hanrek
  2485.  
  2486. The "Building Opendoc with Codwarrior" Folder is only on the
  2487. OpenDoc A6 with source disk, I believe (Jens, can you help
  2488. me out here?).  This is because to use codewarrior you currently
  2489. have to build your part editor inside of opendoc and hence
  2490. requires building opendoc in CW.
  2491.  
  2492. -Ken Prehoda
  2493. kenp@nmrfam.wisc.edu
  2494.  
  2495. +++++++++++++++++++++++++++
  2496.  
  2497. >From lambert_l@measurex.com (Leon Lambert)
  2498. Date: Mon, 15 Aug 1994 17:58:53 GMT
  2499. Organization: measurex
  2500.  
  2501. In article <32ipft$18t@charm.magnus.acs.ohio-state.edu>
  2502. tfullert@bottom.magnus.acs.ohio-state.edu (tfullert) writes:
  2503.  
  2504. > Hi:
  2505. > I was given a copy of MPW 3.3 (not pirated, I was given all of the
  2506. > materials in the huge box),and have the current shell from CodeWarrior.
  2507. >  I am doing all of my own work on CodeWarrior and I want to devote some
  2508. > energy to learning MPW.  What priority should I give this, though. 
  2509. > Exactly what can I do with MPW which I cannot do with CodeWarrior or
  2510. > SC++?
  2511. > Thanks;
  2512. > Tim
  2513.  
  2514. I find the scripting language in MPW to be great. It takes quite an investment
  2515. to learn but really pays off if you have a lot of tedious repetative editing
  2516. to do. I do a lot of porting of code to other platforms and find it very
  2517. useful. The comparefiles script is worth its weight in Gold. I have not
  2518. found a better file comparison utility on any platform out there.
  2519.  
  2520. Since switching to CW I find myself spending about 85% of my time there,
  2521. but still need to switch to MPW to do some fancy stuff. MPW allows you
  2522. to hook your own functions to keys to do fancy editing. For instance
  2523. I can double click a function name and do a cmd 0 and the proper #include
  2524. is inserted at the top of my C file. I wish CW would put some sort
  2525. of scripting/macro ability into their editor.
  2526.  
  2527. lambert_l@measurex.com (Leon Lambert)
  2528. lambertlb@aol.com
  2529.  
  2530. +++++++++++++++++++++++++++
  2531.  
  2532. >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!")
  2533. Date: Tue, 16 Aug 1994 11:10:30 +0800
  2534. Organization: Department of Computer Science, The University of Western Australia
  2535.  
  2536. In article <tree-1508940738330001@155.64.60.63>, tree@bedford.symantec.com
  2537. (Tom Emerson) wrote:
  2538.  
  2539. >So, what features of the MPW editor do you prefer over those provided by
  2540. >any other editor?
  2541.  
  2542. [On no, I'm gonna get in twubble again... (: ]
  2543.  
  2544. #1 most important feature... it edits arbitrary sized files.  I get
  2545. *really* annoyed when I edit a file and programs go "not enough memory to
  2546. edit this document".  But I recognise that this feature is a) hard and b)
  2547. unnecessary for programming.  It's just that MPW has it and no one else
  2548. does.
  2549.  
  2550. I also like the way MPW's command, option & shift arrow keys all seem to
  2551. work they way I expect.  And, if worst comes to worst, I can use SetKey to
  2552. fix them (:
  2553.  
  2554. Double-clicking on brackets to match them!  [Although that's supposed to
  2555. have arrived in CW4.]
  2556.  
  2557. I *really* like MPW's search and replace system, especially the way that
  2558. shift works to search backwards.  I just can't get the the hang of any
  2559. Think editor's search and replace.  CW is good but the non-modal dialog
  2560. just confuses me (:  I also like the power of MPW's regular expressions. 
  2561. [And unlike most of my unix-raised bretheren, I understand them better
  2562. than unix regexs.]
  2563.  
  2564. I also make quite a bit of use adding scripts into menus.
  2565.  
  2566. I suspect that Alpha provides most of the flexibility that I need in an
  2567. editor.  But unfortunately Alpha is both ugly (IMHO of course) and Dvorak
  2568. keyboard unfriendly.  [Yes I know you can tweak it but that's *no*
  2569. excuse.]
  2570.  
  2571. I want MPW's editor ripped out of MPW so that I can use it with CW and TPM
  2572. without blowing away multiple megabytes!!!  We have ToolServer and
  2573. SourceServer, why not EditorServer (:
  2574.  
  2575. Share and Enjoy.
  2576. -- 
  2577. Quinn "The Eskimo!"      <quinn@cs.uwa.edu.au>     "Support HAVOC!"
  2578. Department of Computer Science, The University of Western Australia
  2579.   Who's just come from one flame war in c.s.m.hardware and doesn't
  2580.   really want to start another here ):
  2581.  
  2582. +++++++++++++++++++++++++++
  2583.  
  2584. >From Bruce@hoult.actrix.gen.nz (Bruce Hoult)
  2585. Date: Tue, 16 Aug 1994 16:24:50 +1200 (NZST)
  2586. Organization: (none)
  2587.  
  2588. mclow@san_marcos.csusm.edu (Marshall Clow) writes:
  2589. >    My _favorite_ MPW editor feature is the "double click on open
  2590. > paren/brace/bracket/slash/quote and select everything up to the matching
  2591. > symbol. (Also works with 2x-clicking on the closing symbol. If you hold
  2592. > the mouse button down after the second click, you can move the cursor
  2593. > around and see the selection change to show differing "matches"
  2594. > MUCH, much better than the "Balance" command in Think.
  2595.  
  2596. Holy cow!
  2597.  
  2598. I've been using MPW since 1987, and have used the "double-click on a bracket"
  2599. feature forever, but I've never discovered the "hold the button down"
  2600. feature.
  2601.  
  2602. Cool!
  2603.  
  2604. -- Bruce
  2605.  
  2606. +++++++++++++++++++++++++++
  2607.  
  2608. >From stevec@jolt.mpx.com.au (Stephen F Coy)
  2609. Date: 16 Aug 1994 10:23:29 GMT
  2610. Organization: Microplex Pty Ltd
  2611.  
  2612. Quinn "The Eskimo! (quinn@cs.uwa.edu.au) wrote:
  2613. : In article <tree-1508940738330001@155.64.60.63>, tree@bedford.symantec.com
  2614. : (Tom Emerson) wrote:
  2615.  
  2616. : >So, what features of the MPW editor do you prefer over those provided by
  2617. : >any other editor?
  2618.  
  2619. : [On no, I'm gonna get in twubble again... (: ]
  2620.  
  2621. : #1 most important feature... it edits arbitrary sized files.  I get
  2622. : *really* annoyed when I edit a file and programs go "not enough memory to
  2623. : edit this document".  But I recognise that this feature is a) hard and b)
  2624. : unnecessary for programming.  It's just that MPW has it and no one else
  2625. : does.
  2626.  
  2627. : I also like the way MPW's command, option & shift arrow keys all seem to
  2628. : work they way I expect.  And, if worst comes to worst, I can use SetKey to
  2629. : fix them (:
  2630.  
  2631. : Double-clicking on brackets to match them!  [Although that's supposed to
  2632. : have arrived in CW4.]
  2633.  
  2634. : I *really* like MPW's search and replace system, especially the way that
  2635. : shift works to search backwards.  I just can't get the the hang of any
  2636. : Think editor's search and replace.  CW is good but the non-modal dialog
  2637. : just confuses me (:  I also like the power of MPW's regular expressions. 
  2638. : [And unlike most of my unix-raised bretheren, I understand them better
  2639. : than unix regexs.]
  2640.  
  2641. : I also make quite a bit of use adding scripts into menus.
  2642.  
  2643. : I suspect that Alpha provides most of the flexibility that I need in an
  2644. : editor.  But unfortunately Alpha is both ugly (IMHO of course) and Dvorak
  2645. : keyboard unfriendly.  [Yes I know you can tweak it but that's *no*
  2646. : excuse.]
  2647.  
  2648. : I want MPW's editor ripped out of MPW so that I can use it with CW and TPM
  2649. : without blowing away multiple megabytes!!!  We have ToolServer and
  2650. : SourceServer, why not EditorServer (:
  2651.  
  2652. : Share and Enjoy.
  2653. : -- 
  2654. : Quinn "The Eskimo!"      <quinn@cs.uwa.edu.au>     "Support HAVOC!"
  2655. : Department of Computer Science, The University of Western Australia
  2656. :   Who's just come from one flame war in c.s.m.hardware and doesn't
  2657. :   really want to start another here ):
  2658.  
  2659. I could not have said this better myself. In fact, one of the reasons I 
  2660. like Object Master so much is that it emulates (mostly anyway) the 
  2661. keyboard and search/replace behaviour of MPW. Everytime I fire up the 
  2662. Symantec C++ IDE, the editor drives me nuts in short order.
  2663.  
  2664.  
  2665. - ------
  2666. Steve Coy
  2667. Resolve Software (WA) Pty Ltd
  2668. Sydney Australia
  2669.  
  2670.  
  2671. +++++++++++++++++++++++++++
  2672.  
  2673. >From Willie Abrams <willie-abrams@uokhsc.edu>
  2674. Date: 16 Aug 1994 13:21:15 GMT
  2675. Organization: OU Health Sciences Center
  2676.  
  2677. In article <tree-1508940738330001@155.64.60.63> Tom Emerson,
  2678. tree@bedford.symantec.com writes:
  2679. >So, what features of the MPW editor do you prefer over those provided by
  2680. >any other editor?
  2681.  
  2682. Tom, hate to make a pointed remark...MPW can open up files
  2683. to just look at and edit individually (unlike TPM, where I can't
  2684. unless I have a project open.)
  2685.  
  2686. It is a small, but modal inconvenience that keeps me from even
  2687. going to TPM look at hardly any source files - I find myself
  2688. dragging and dropping on to BBEdit Lite.
  2689.  
  2690. Willie Abrams                                  willie-abrams@uokhsc.edu
  2691. Telemedicine Software Guy                     OU Health Sciences Center
  2692.  
  2693. It's a classic Pincer's Movement. It can't fail against a ten-year-old!
  2694.  
  2695. +++++++++++++++++++++++++++
  2696.  
  2697. >From Willie Abrams <willie-abrams@uokhsc.edu>
  2698. Date: 16 Aug 1994 13:22:35 GMT
  2699. Organization: OU Health Sciences Center
  2700.  
  2701. In article <quinn-1608941110300001@edu-dynamic1.educ.ecel.uwa.edu.au>
  2702. Quinn, quinn@cs.uwa.edu.au writes:
  2703. >unnecessary for programming.  It's just that MPW has it and no one else
  2704. >does.
  2705.  
  2706. BBEdit hardly ever has this problem...
  2707.  
  2708. Willie Abrams                                  willie-abrams@uokhsc.edu
  2709. Telemedicine Software Guy                     OU Health Sciences Center
  2710.  
  2711. It's a classic Pincer's Movement. It can't fail against a ten-year-old!
  2712.  
  2713. +++++++++++++++++++++++++++
  2714.  
  2715. >From tree@bedford.symantec.com (Tom Emerson)
  2716. Date: Tue, 16 Aug 1994 15:30:56 -0500
  2717. Organization: Symantec Development Tools Group
  2718.  
  2719. In article <32qegb$36f@romulus.ucs.uoknor.edu>, Willie Abrams
  2720. <willie-abrams@uokhsc.edu> wrote:
  2721.  
  2722. > In article <tree-1508940738330001@155.64.60.63> Tom Emerson,
  2723. > tree@bedford.symantec.com writes:
  2724. > >So, what features of the MPW editor do you prefer over those provided by
  2725. > >any other editor?
  2726. > Tom, hate to make a pointed remark...MPW can open up files
  2727. > to just look at and edit individually (unlike TPM, where I can't
  2728. > unless I have a project open.)
  2729.  
  2730. Sure, I understand. But that is an environment issue, not an editor issue.
  2731. Just picking nits ;-) This is something that is, contrary to many peoples
  2732. belief, something that is non-trivial to change in the design of the TPM,
  2733. not that it hasn't been discussed. Who knows what the future may hold,
  2734. though.
  2735.  
  2736.    -tre
  2737.  
  2738. -- 
  2739. Tom Emerson                                              Software Engineer
  2740. Development Tools Group                               Symantec Corporation
  2741.                           tree@bedford.symantec.com
  2742.   "I dreamed I had to take a test, in a Dairy Queen, on another planet."
  2743.  
  2744. +++++++++++++++++++++++++++
  2745.  
  2746. >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!")
  2747. Date: Wed, 17 Aug 1994 10:12:19 +0800
  2748. Organization: Department of Computer Science, The University of Western Australia
  2749.  
  2750. In article <32qeir$36f@romulus.ucs.uoknor.edu>, Willie Abrams
  2751. <willie-abrams@uokhsc.edu> wrote:
  2752.  
  2753. >BBEdit hardly ever has this problem...
  2754.  
  2755. Yeah, I know, BBEdit uses temporary memory.  But it still bites me.  I
  2756. only have 20MB (: and when I'm programming and documenting XCMDs I need
  2757. MPW, HyperCard and my documentation tools open all at once which means
  2758. that I regularly run out of temporary memory.  Then I got to poke around
  2759. in a PostScript file at the same time...
  2760.  
  2761. Just one of those inconveniences that I can do without.  And given the
  2762. other advantages of MPW's editor.
  2763. -- 
  2764. Quinn "The Eskimo!"      <quinn@cs.uwa.edu.au>     "Support HAVOC!"
  2765. Department of Computer Science, The University of Western Australia
  2766.   And don't even mention LabView.
  2767.  
  2768. +++++++++++++++++++++++++++
  2769.  
  2770. >From Manuel Veloso <veloso@netcom.com>
  2771. Date: Wed, 17 Aug 1994 07:35:44 GMT
  2772. Organization: Ibex Productions
  2773.  
  2774. In article <32qeir$36f@romulus.ucs.uoknor.edu> Willie Abrams, willie-abrams@uokhsc.edu
  2775. writes:
  2776. >Quinn, quinn@cs.uwa.edu.au writes:
  2777. >>unnecessary for programming.  It's just that MPW has it and no one else
  2778. >>does.
  2779. >
  2780. >BBEdit hardly ever has this problem...
  2781.  
  2782. Actually, I was dealing with Postscript files a while back, and MPW
  2783. is the only editor (besides MS Word) that would open them - no matter
  2784. how big (ie: a couple of megs). Of course, I could have changed
  2785. BBEdit's partition size, but I use it as my 'normal' editor
  2786. and wouldn't want to keep changing it.
  2787.  
  2788. BBEdit's major strength, IMO, is its multi-file search browser.
  2789. Too bad you can't edit in it, though.
  2790.  
  2791. +++++++++++++++++++++++++++
  2792.  
  2793. >From Manuel Veloso <veloso@netcom.com>
  2794. Date: Wed, 17 Aug 1994 07:43:10 GMT
  2795. Organization: Ibex Productions
  2796.  
  2797. In article <32ipft$18t@charm.magnus.acs.ohio-state.edu> tfullert,
  2798. tfullert@bottom.magnus.acs.ohio-state.edu writes:
  2799. >Exactly what can I do with MPW which I cannot do with CodeWarrior or
  2800. >SC++?
  2801.  
  2802. Well, there are three main things:
  2803.  
  2804. (1) you can do a multitude of incredibly complicated things with MPW's
  2805. scripting language/makefiles. In essence, you have complete control
  2806. over the shell, and can issue commands, etc.
  2807.  
  2808. (2) you can have completely integrated projector support (how many
  2809. times have you moved a ProjectorDB file and gotten the "can't check in
  2810. file blah because the project was not found" using the TPM/SS combo?
  2811. This never happens w/Projector. Plus, check in active/check out active
  2812. work, and the checkin window doesn't take forever in MPW.)
  2813.  
  2814. (3) You can be macho <-- arguably the most important thing you can't do
  2815.                          if you use CW/SymC
  2816.  
  2817. +++++++++++++++++++++++++++
  2818.  
  2819. >From Manuel Veloso <veloso@netcom.com>
  2820. Date: Wed, 17 Aug 1994 07:46:44 GMT
  2821. Organization: Ibex Productions
  2822.  
  2823. In article <quinn-1508941430460001@edu-dynamic1.educ.ecel.uwa.edu.au> Quinn,
  2824. quinn@cs.uwa.edu.au writes:
  2825. >>Yeah, it's a bummer when a tool dies, since it takes the shell with it.
  2826. >>Oh, well.
  2827. >
  2828. >The tool has to die pretty badly for "g sysrecover" to fail.
  2829.  
  2830. You can also use "g stoptool". I'm not sure which one's recommended, though.
  2831.  
  2832. +++++++++++++++++++++++++++
  2833.  
  2834. >From bix.com!dvanhoozer
  2835. Date: 17 Aug 1994 08:53:26 GMT
  2836. Organization: Mad Bomber Software
  2837.  
  2838. In article <2859899090@hoult.actrix.gen.nz> Bruce@hoult.actrix.gen.nz (Bruce
  2839. Hoult) writes:
  2840. >mclow@san_marcos.csusm.edu (Marshall Clow) writes:
  2841. >> the mouse button down after the second click, you can move the cursor
  2842. >> around and see the selection change to show differing "matches"
  2843. >> 
  2844. >> MUCH, much better than the "Balance" command in Think.
  2845. >
  2846. >Holy cow!
  2847. >
  2848. >I've been using MPW since 1987, and have used the "double-click on a bracket"
  2849. >feature forever, but I've never discovered the "hold the button down"
  2850. >feature.
  2851.  
  2852. My face is just as red BH, like you that one has some how
  2853. got past me.  I wonder what else I don't know....   :-)
  2854.  
  2855. Dewayne
  2856.   o-*
  2857.  
  2858.  
  2859.  
  2860. +++++++++++++++++++++++++++
  2861.  
  2862. >From Bruce@hoult.actrix.gen.nz (Bruce Hoult)
  2863. Date: Thu, 18 Aug 1994 03:17:32 +1200 (NZST)
  2864. Organization: (none)
  2865.  
  2866. Manuel Veloso <veloso@netcom.com> writes:
  2867. > Actually, I was dealing with Postscript files a while back, and MPW
  2868. > is the only editor (besides MS Word) that would open them - no matter
  2869. > how big (ie: a couple of megs). Of course, I could have changed
  2870. > BBEdit's partition size, but I use it as my 'normal' editor
  2871. > and wouldn't want to keep changing it.
  2872.  
  2873. BBEdit lets you open any size file without changing the partition
  2874. size -- it uses System memory.
  2875.  
  2876. In my moonlighting job as a consultant to a DTP company, I often use
  2877. BBEdit to edit PostScript files of up to 80 or 100 MB in size.  It
  2878. handles it without a complaint, with very good performance (once the
  2879. file is all read into memory), in the standard BBEdit memory partition.
  2880.  
  2881. MPW and Word simply can't cope with files this size with any sort of
  2882. performance at all.  You done good, Rich.
  2883.  
  2884. This *is* on a Q950 with 136 MB of RAM, mind you.
  2885.  
  2886. -- Bruce
  2887.  
  2888. +++++++++++++++++++++++++++
  2889.  
  2890. >From mem@pha.jhu.edu (Mel Martinez)
  2891. Date: Wed, 17 Aug 1994 15:57:25 -0500
  2892. Organization: The Johns Hopkins Univ. - Dept. of Physics
  2893.  
  2894. In article <2860024652@hoult.actrix.gen.nz>, Bruce@hoult.actrix.gen.nz
  2895. (Bruce Hoult) wrote:
  2896.  
  2897. > Manuel Veloso <veloso@netcom.com> writes:
  2898. > > Actually, I was dealing with Postscript files a while back, and MPW
  2899. > > is the only editor (besides MS Word) that would open them - no matter
  2900. > > how big (ie: a couple of megs). Of course, I could have changed
  2901. > > BBEdit's partition size, but I use it as my 'normal' editor
  2902. > > and wouldn't want to keep changing it.
  2903. > BBEdit lets you open any size file without changing the partition
  2904. > size -- it uses System memory.
  2905. > In my moonlighting job as a consultant to a DTP company, I often use
  2906. > BBEdit to edit PostScript files of up to 80 or 100 MB in size.  It
  2907. > handles it without a complaint, with very good performance (once the
  2908. > file is all read into memory), in the standard BBEdit memory partition.
  2909. > MPW and Word simply can't cope with files this size with any sort of
  2910. > performance at all.  You done good, Rich.
  2911. > This *is* on a Q950 with 136 MB of RAM, mind you.
  2912. > -- Bruce
  2913.  
  2914.  
  2915. Err.. thank you.  You may sit down now, please.  :-)
  2916.  
  2917. Now back to dealing with problems for 'the rest of us' (with single &
  2918. double digit memory)...
  2919.  
  2920. Sheesh!
  2921.  
  2922. Mel
  2923.  
  2924. +++++++++++++++++++++++++++
  2925.  
  2926. >From siegel@netcom.com (Rich Siegel)
  2927. Date: Wed, 17 Aug 1994 19:36:24 GMT
  2928. Organization: Bare Bones Software
  2929.  
  2930. In article <2860024652@hoult.actrix.gen.nz> Bruce@hoult.actrix.gen.nz (Bruce Hoult) writes:
  2931. >In my moonlighting job as a consultant to a DTP company, I often use
  2932. >BBEdit to edit PostScript files of up to 80 or 100 MB in size.  It
  2933. >handles it without a complaint, with very good performance (once the
  2934. >file is all read into memory), in the standard BBEdit memory partition.
  2935. >
  2936. >MPW and Word simply can't cope with files this size with any sort of
  2937. >performance at all.  You done good, Rich.
  2938.  
  2939. I appreciate the compliment, but in good conscience can't take -all-
  2940. the credit. The text engine was original written by Jon Hueras, with
  2941. modifications by me, and Jon also did the rewrite for PowerPC.
  2942.  
  2943. (That won't stop me from taking -some- of the credit, though. :-])
  2944.  
  2945. R.
  2946. -- 
  2947. Rich Siegel % siegel@netcom.com    % President & CEO, Bare Bones Software Inc.
  2948. --> For information about BBEdit, finger bbedit@world.std.com <--
  2949.  
  2950. +++++++++++++++++++++++++++
  2951.  
  2952. >From mxmora@unix.sri.com (Matt Mora)
  2953. Date: 17 Aug 1994 13:43:17 -0700
  2954. Organization: SRI International, Menlo Park, CA
  2955.  
  2956. In article <tree-1608941530560001@155.64.60.63> tree@bedford.symantec.com (Tom Emerson) writes:
  2957.  
  2958. >Sure, I understand. But that is an environment issue, not an editor issue.
  2959. >Just picking nits ;-) This is something that is, contrary to many peoples
  2960. >belief, something that is non-trivial to change in the design of the TPM,
  2961. >not that it hasn't been discussed. Who knows what the future may hold,
  2962. >though.
  2963.  
  2964. We have seen the future (rainbow that is) and you better hurry
  2965. up and make it so or else you won't have a market left. 
  2966.  
  2967.  
  2968. Xavier
  2969.  
  2970.  
  2971.  
  2972.  
  2973.  
  2974.  
  2975. -- 
  2976. ___________________________________________________________
  2977. Matthew Xavier Mora                       Matt_Mora@sri.com
  2978. SRI International                       mxmora@unix.sri.com
  2979. 333 Ravenswood Ave                    Menlo Park, CA. 94025
  2980.  
  2981. +++++++++++++++++++++++++++
  2982.  
  2983. >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University)
  2984. Date: 19 Aug 94 16:05:30 +1200
  2985. Organization: University of Waikato, Hamilton, New Zealand
  2986.  
  2987. In article <tree-1508940738330001@155.64.60.63>, tree@bedford.symantec.com (Tom Emerson) writes:
  2988. > In article <quinn-1508941433320001@edu-dynamic1.educ.ecel.uwa.edu.au>,
  2989. > quinn@cs.uwa.edu.au (Quinn "The Eskimo!") wrote:
  2990. >
  2991. >> Besides [warning, holy way bait!] MPW's editor is *sooo* much better than
  2992. >> any other editor on the Mac.
  2993. >
  2994. > So, what features of the MPW editor do you prefer over those provided by
  2995. > any other editor?
  2996.  
  2997. Of course, one of the things that gets me waxing so lyrical is that MPW is
  2998. so much more than just an editor.
  2999.  
  3000. On more than one occasion now, I've been involved in upgrading our
  3001. departmental AppleShare server. We've been through 2-3 hard disk upgrades
  3002. and one change of machine over the past couple of years. Each time, of course,
  3003. I've had to copy all the files from the old hard disk to the new one, and
  3004. preserve all their folder protections. I've never bothered getting any
  3005. proper backup software to do this, since I've made it quite clear to our users
  3006. that they have to back up their own data, all I'm responsible for is the
  3007. server configuration itself.
  3008.  
  3009. The file-copying part was never a big deal: I just drag everything across
  3010. in the Finder, and leave it copying for a few hours, or overnight, or whatever.
  3011. For transferring the folder protections (and for backing them up), I use MPW.
  3012.  
  3013. The MPW Shell has this neat convention in some commands: it uses the same
  3014. command for both examining a setting and for changing it. The clever thing is,
  3015. when you ask the command to display the existing setting, it outputs a command
  3016. which can be used to set the setting to that value. For example, the
  3017. SetPrivilege tool lets you examine and change folder protections. The command
  3018. "SetPrivilege -i" displays the current protections in the form of "SetPrivilege"
  3019. commands. So to dump out all the existing protections on the old volume, I
  3020. issued the command:
  3021.  
  3022.     SetPrivilege -i -r "OldVolume:"
  3023.  
  3024. (the -r option says to recursively list subfolders as well). Then I did a
  3025. global search and replace on the output, replacing all occurrences of OldVolume
  3026. with NewVolume, and finally I selected the result and pressed Enter to
  3027. execute it. Voila! All the protections transferred with a minimum of work.
  3028.  
  3029. As I keep saying, if you can't do it with MPW, it isn't worth doing. :-)
  3030.  
  3031. Lawrence D'Oliveiro                       fone: +64-7-856-2889
  3032. Info & Tech Services Division              fax: +64-7-838-4066
  3033. University of Waikato            electric mail: ldo@waikato.ac.nz
  3034. Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
  3035.  
  3036. +++++++++++++++++++++++++++
  3037.  
  3038. >From Jens Alfke <jens_alfke@powertalk.apple.com>
  3039. Date: Fri, 19 Aug 1994 23:32:41 GMT
  3040. Organization: Apple Computer
  3041.  
  3042. Kenneth Prehoda, kenp@tuli writes:
  3043. > The "Building Opendoc with Codwarrior" Folder is only on the
  3044. > OpenDoc A6 with source disk, I believe (Jens, can you help
  3045. > me out here?).  This is because to use codewarrior you currently
  3046. > have to build your part editor inside of opendoc and hence
  3047. > requires building opendoc in CW.
  3048.  
  3049. You're 100% right. I guess it might have been possible to precompile all the
  3050. OD code into a library that you'd link into an app along with your part
  3051. implementation, but I didn't have time to do that.
  3052.  
  3053. Of course the beta release will work fine with CodeWarrior (in fact that's
  3054. what we do our primary development with now, with brief excursions to MPW to
  3055. run the SOM compiler.)
  3056.  
  3057. --Jens Alfke                           jens_alfke@powertalk.apple.com
  3058.                    "A man, a plan, a yam, a can of Spam ... Bananama!"
  3059.  
  3060. +++++++++++++++++++++++++++
  3061.  
  3062. >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!")
  3063. Date: Sun, 21 Aug 1994 14:58:28 +0800
  3064. Organization: Department of Computer Science, The University of Western Australia
  3065.  
  3066. In article <tree-1608941530560001@155.64.60.63>, tree@bedford.symantec.com
  3067. (Tom Emerson) wrote:
  3068.  
  3069. >This is something that is, contrary to many peoples
  3070. >belief, something that is non-trivial to change in the design of the TPM [...]
  3071.  
  3072. Working as designed ):
  3073. -- 
  3074. Quinn "The Eskimo!"      <quinn@cs.uwa.edu.au>     "Support HAVOC!"
  3075. Department of Computer Science, The University of Western Australia
  3076. >From eric.larson@f620.n2605.z1.fidonet.org (eric larson)
  3077. Subject: What is the point of MPW?
  3078. Date: 18 Aug 94 19:11:49 -
  3079. Organization: FidoNet: Shockwave Rider, USR V.Everything +1(908)294-0659 
  3080.  
  3081.  >>MPW and Word simply can't cope with files this size with any sort of
  3082.  >>performance at all.  You done good, Rich.
  3083.  
  3084.  > I appreciate the compliment, but in good conscience can't take -all-
  3085.  > the credit. The text engine was original written by Jon Hueras, with
  3086.  > modifications by me, and Jon also did the rewrite for PowerPC.
  3087.  
  3088. I've had similar experiences with BBEdit. When making literally thousands of
  3089. changes using search and replace on a 10 MB text file, every other editor I've
  3090. tried chokes. BBEdit handles the job smoothly, without complaint.
  3091.  
  3092. +++++++++++++++++++++++++++
  3093.  
  3094. >From khatt@shell.portal.com (Judy Ann Kettenhofen)
  3095. Date: 28 Aug 1994 21:52:51 GMT
  3096. Organization: Portal Communications Company -- 408/973-9111 (voice) 408/973-8091 (data)
  3097.  
  3098. eric larson (eric.larson@f620.n2605.z1.fidonet.org) wrote:
  3099. :  >>MPW and Word simply can't cope with files this size with any sort of
  3100. :  >>performance at all.  You done good, Rich.
  3101.  
  3102. :  > I appreciate the compliment, but in good conscience can't take -all-
  3103. :  > the credit. The text engine was original written by Jon Hueras, with
  3104. :  > modifications by me, and Jon also did the rewrite for PowerPC.
  3105.  
  3106. : I've had similar experiences with BBEdit. When making literally thousands of
  3107. : changes using search and replace on a 10 MB text file, every other editor I've
  3108. : tried chokes. BBEdit handles the job smoothly, without complaint.
  3109.  
  3110. Sorry, I didn't see the first part of this message.
  3111. In general, MPW should have problems with large files in two cases:
  3112. 1) Where there are a large number of markers
  3113. 2) Where you make a lot of changes.
  3114.  
  3115. For the first, you are out of luck, to the best of my knowledge.
  3116. For the second, you can do some things to help.
  3117. 1. Save your file frequently after changes.
  3118.    This helps MPW Shell to basically do garbage collection, and
  3119.    requires less of the file to be resident in memory.
  3120. 2. There is a way to change the size of the editor heap.
  3121.    I don't recall what it is right now.  If you know you
  3122.    are going to have large files, you can try enlarging the editor heap.
  3123. The MPW Shell has code to create subsequent editor heaps if it runs
  3124. out of space in the first one, but I don't think that code has been
  3125. exercised much.
  3126.  
  3127. --Judy
  3128.  
  3129. --former MPW hack.
  3130.  
  3131.  
  3132. +++++++++++++++++++++++++++
  3133.  
  3134. >From dlopez@sailsun (Dean Lopez)
  3135. Date: 30 Aug 1994 13:00:34 GMT
  3136. Organization: NASA Johnson Space Center, Houston, TX, USA
  3137.  
  3138. eric larson (eric.larson@f620.n2605.z1.fidonet.org) wrote:
  3139. > I've had similar experiences with BBEdit. When making literally thousands of
  3140. > changes using search and replace on a 10 MB text file, every other editor I've
  3141. > tried chokes. BBEdit handles the job smoothly, without complaint.
  3142.  
  3143. I just started using BBEdit Lite (v2.3? - whatever the latest rev is), and I've
  3144. noticed whenever I open an existing file, BBEdit promptly puts a single
  3145. garbage character at the end of my file.  It doesn't mark the file as 'dirty'
  3146. though, so if I close the file, the garbage character doesn't get saved to
  3147. the file.  If I make any edits to the file and THEN save, the garbage character
  3148. ends up at the end of my file, which promptly causes my compiler to complain.
  3149. Has anyone had this problem with the commercial BBEdit?
  3150. --
  3151. +--------------------------------------+------------------------------+
  3152. | Dean Lopez                           |                              |
  3153. | SAIL DPS Engineer                    | dlopez@sailsun.jsc.nasa.gov  |
  3154. | Rockwell Space Operations Co.        | deanlopez@aol.com            |
  3155. | JSC Shuttle Avionics Integration Lab | dean_lopez@maclair.sccsi.com |
  3156. +--------------------------------------+------------------------------+
  3157. #include <standard_disclaimer.h>
  3158. /* The opinions expressed are all mine.
  3159.    RSOC doesn't speak for me and I don't speak for RSOC
  3160.    After all, I'm only an engineer - what do I know?     */
  3161.  
  3162. ---------------------------
  3163.  
  3164. >From netcom.com!kira!davidjohn (David John Burrowes)
  3165. Subject: Where have the standards gone? [a high level question]
  3166. Date: Fri, 19 Aug 1994 03:17:20 GMT
  3167. Organization: No organization at this time.
  3168.  
  3169. I was reading the article about System 7.5 in the September 1994 issue of  
  3170. MacUser (p. 79-84), and it raised a gigantic question in my mind.  After  
  3171. some thought, I decided to see what opinions others (yourselves) might have.
  3172.  
  3173. The 'screenshots' on pages 80-81 and 82-83 of the above issue shows several  
  3174. new features of this system software release.  In them, I noted five new  
  3175. window styles:
  3176. - a strange little thing for 'post-it' notes
  3177. - a green one for the CD player (the title bar is similar to the standard
  3178.   document titlebar, but not the same)
  3179. - the Find File windows have a funky styled background
  3180. - the Launcher window gives us a window with, presumably, a standard pink
  3181.   background with square/tile/chicklet(sp?) icons
  3182. - A window that is reminiscent of the 'palette' titlebar, but with close
  3183.   and zoom boxes.
  3184. (the TV stuff in another article has yet another window style variation).
  3185.  
  3186. For buttons, I notice these new styles (in *addition* to standard flat Mac  
  3187. push-buttons)
  3188. - '3D' buttons in the Launcher window,
  3189. - two types of CD player-like buttons in the CD player window (also found on
  3190.   the TV control panel in that other article)
  3191. - plus, two other '3D' styles for the help system (one with icons, and
  3192.   one that looks like 'shallow' buttons at the bottom of the
  3193.   palette-ish windows.
  3194. (plus, what looks like another '3d'ish style is seen in the TV control  
  3195. panel)
  3196.  
  3197. Individually, many of these don't look that bad, I suppose (but, that's  
  3198. another issue, really).  However, as I recall, one of the advertised  
  3199. strengths of the Macintosh, in past years, was its highly consistent  
  3200. interface.  Buttons looked and behaved the same everywhere.  Windows with a  
  3201. particular style almost always behaved the same as other windows with the  
  3202. same style.  Etc.
  3203. I find myself concerned, therefore, with all of these new innovations.  I do  
  3204. not see a great deal of consistency here.  What kind of message is this  
  3205. sending to developers? It seems to me it's something like, 'Sure, go ahead,  
  3206. bypass the toolbox (as I assume some or much of the above stuff is). Make up  
  3207. whatever non-standard user interface features you want so your app looks  
  3208. unusual and snazzy. Users will figure it out eventually.'
  3209. Sure, I know, some developers have always felt compelled to do things their  
  3210. own way.  But, since this is Apple doing non-standard things, many more  
  3211. people will feel justified in going off and doing *their own* things.  By  
  3212. itself, I find this to be a depressing prospect.  But, with Microsoft coming  
  3213. out with a significantly improved user interface for Windows soon (Chicago),  
  3214. this all strikes me as Apple shooting itself in the foot, bigtime, which I  
  3215. find more depressing still.
  3216.  
  3217. If you've read this far, I'm curious what your thoughts are, either through  
  3218. personal email or on the newsgroup.  Maybe I'm very much in the minority,  
  3219. and folks generally think the 'highly consistent' interface was too  
  3220. constraining?
  3221.  
  3222. Thanks.
  3223.  
  3224. david john burrowes
  3225. davidjohn@kira.net.netcom.com
  3226.  
  3227.  
  3228. +++++++++++++++++++++++++++
  3229.  
  3230. >From wysocki@netcom.com (Chris Wysocki)
  3231. Date: Fri, 19 Aug 1994 09:51:10 GMT
  3232. Organization: NETCOM On-line Communication Services (408 261-4700 guest)
  3233.  
  3234. In article <1994Aug19.031720.1465@kira.net.netcom.com>,
  3235. David John Burrowes <netcom.com!kira!davidjohn> wrote:
  3236.  
  3237. >I find myself concerned, therefore, with all of these new innovations.  I do  
  3238. >not see a great deal of consistency here.  What kind of message is this  
  3239. >sending to developers? It seems to me it's something like, 'Sure, go ahead,  
  3240. >bypass the toolbox (as I assume some or much of the above stuff is). Make up  
  3241. >whatever non-standard user interface features you want so your app looks  
  3242. >unusual and snazzy. Users will figure it out eventually.'
  3243. >Sure, I know, some developers have always felt compelled to do things their  
  3244. >own way.  But, since this is Apple doing non-standard things, many more  
  3245. >people will feel justified in going off and doing *their own* things.  By  
  3246. >itself, I find this to be a depressing prospect.  But, with Microsoft coming  
  3247. >out with a significantly improved user interface for Windows soon (Chicago),  
  3248. >this all strikes me as Apple shooting itself in the foot, bigtime, which I  
  3249. >find more depressing still.
  3250.  
  3251. I wholeheartedly concur.  Apple has done far too little in recent
  3252. years to promote UI consistency across applications.  Their reluctance
  3253. to provide standard implementations of UI features such as floating
  3254. windows, menus with multiple-modifier keyboard shortcuts, and basic
  3255. controls such as up-down arrows, sliders and progress bars have forced
  3256. developers to implement these features themselves, with varying and
  3257. sometimes inconsistent results.  At the Worldwide Developers
  3258. Conference in May some Apple engineers spoke in nebulous terms about
  3259. future UI enhancements which are coming down the road, but it struck
  3260. me and others with whom I spoke as too little, too late....
  3261.  
  3262. Chris.
  3263.  
  3264. +++++++++++++++++++++++++++
  3265.  
  3266. >From pcastine@prz.tu-berlin.de (Peter Castine)
  3267. Date: Fri, 19 Aug 1994 11:11:19 GMT
  3268. Organization: Process Control Center
  3269.  
  3270. In article <1994Aug19.031720.1465@kira.net.netcom.com>,
  3271. netcom.com!kira!davidjohn (David John Burrowes) wrote:
  3272.  
  3273. > I was reading the article about System 7.5 in the September 1994 issue of  
  3274. > MacUser (p. 79-84), and it raised a gigantic question in my mind.  After  
  3275. > some thought, I decided to see what opinions others (yourselves) might have.
  3276. > The 'screenshots' on pages 80-81 and 82-83 of the above issue shows several  
  3277. > new features of this system software release.  In them, I noted five new  
  3278. > window styles:
  3279.  
  3280. [schnipp...]
  3281.  
  3282. > If you've read this far, I'm curious what your thoughts are, either through  
  3283. > personal email or on the newsgroup.  Maybe I'm very much in the minority,  
  3284. > and folks generally think the 'highly consistent' interface was too  
  3285. > constraining?
  3286.  
  3287. I think the subject is worthy of general discussion, so I'll post; in any
  3288. case, our mail server is currently down.
  3289.  
  3290. It seems to me that standards are going out the window, and that this is a
  3291. negative development. Conventional buttons and WDEFs may seem a little
  3292. unadventurous, but in day-to-day work the security of knowing how to
  3293. recognize a button and where the window title is are a great advantage. I
  3294. always disliked HyperCard's anything-can-be-a-button attitude, because it
  3295. leaves you with the challenge of clicking on *everything*, just to see if
  3296. maybe that little chicklet-shaped object triggers some sort of action.
  3297. This is fine and dandy for an adventure game, but frustrating when you're
  3298. trying to get on with your work.
  3299.  
  3300. As one example, I was looking at the new(ish) AppleCD Audio Player. The
  3301. only reason I even tried clicking on the little green triangle in the
  3302. lower left corner was because I knew that the fore-runner software had a
  3303. track list and I was sure that the newer software _must_ have a track list
  3304. somewhere. I looked in the menus, to no avail, so I started clicking
  3305. around and the mouse finally landed on said triangle. Voila! Success at
  3306. last!
  3307.  
  3308. But, why the hell should I spend my time clicking around a window to find
  3309. a substitute for the Zoom box? (Use of the zoom box as a sort of
  3310. {show|hide}-details-of-a-dialog-window is not officially sanctioned, but
  3311. has found it's way into a number of utility programs). Sure, if I'd turned
  3312. on Balloon Help, I might have found this button sooner, but an experienced
  3313. Mac user shouldn't need Balloon Help to find an _Ersatz_ zoom box.
  3314.  
  3315. That said, let me add that it *is* important for UIs to develop; I'm not
  3316. going to advocate cast-in-platinum Human Interface Guidelines. The
  3317. _Macintosh Humand Interface Guidelines_ discuss the subject of ``Going
  3318. Beyond the Guidelines'' quite specifically. 
  3319.  
  3320. The problem with System 7.5 seems to be that Apple has simply integrated a
  3321. couple of 3rd party extensions where graphic design went out of control,
  3322. and nobody bothered to talk with Human Interface about what was good, bad,
  3323. or useful. 
  3324.  
  3325. There is considerable irony in this, in light of Pete Bickford's article
  3326. in the August _AppleDirections_.
  3327.  
  3328. Of course, if you want to see some really funky non-standard windows, look
  3329. at any of the MIDI Products coming from Mark of the Unicorn. Users cried
  3330. bloody murder when MotU introduced it's ``Miami Vice'' look, but MotU has
  3331. stayed with it. The ``Mini-Menu'' that was added to most windows are
  3332. arguably functional, but, even after using their software for several
  3333. years, I fail to recognize the advantage of a triangular close box or a
  3334. misplaced zoom box.
  3335.  
  3336. So, in short: yes, this bothers me. Who else?
  3337.  
  3338. -- 
  3339. Peter Castine               | In old days books were written by men of
  3340. pcastine@prz.tu-berlin.de   | letters and read by the public. Nowadays books 
  3341. Process Control Center      | are written by the public and read by nobody.
  3342. Technical University Berlin |                                 -- Oscar Wilde
  3343.  
  3344. +++++++++++++++++++++++++++
  3345.  
  3346. >From rmah@panix.com (Robert Mah)
  3347. Date: Fri, 19 Aug 1994 08:19:17 -0500
  3348. Organization: One Step Beyond
  3349.  
  3350. netcom.com!kira!davidjohn (David John Burrowes) wrote:
  3351.  
  3352. ) ...
  3353. ) Individually, many of these don't look that bad, I suppose (but, that's  
  3354. ) another issue, really).  However, as I recall, one of the advertised  
  3355. ) strengths of the Macintosh, in past years, was its highly consistent  
  3356. ) interface.  Buttons looked and behaved the same everywhere.  Windows  
  3357. ) with a particular style almost always behaved the same as other windows
  3358. ) with the same style.  Etc.
  3359.  
  3360. I wholeheartedly concur.  Apple's HIG seems to have lost its way -- either
  3361. that or they have lost their authority to override developer's and 
  3362. designers taste for the strange.  One would expect that with Don Norman in
  3363. charge (he is in charge of HIG isn't he?) that HIG would be less worried
  3364. over the "look" and more about the "feel".  That they would hire fewer
  3365. graphic designers and more people versed in psychology and sociology.
  3366.  
  3367. For example, a few months ago there were threads here and on AppleLink
  3368. about the new windoid look used for Apple Guide.  Apple's first excuse was
  3369. that they "did research" and discovered that the de-facto standard for
  3370. floating palette title bars was too small a target.  Fine, why didn't they
  3371. simply make the de-facto standard a couple pixels taller?  Noooo, instead
  3372. then said that they hired some graphics designer (as if graphic designers
  3373. somehow are better at human interface design...).  Of COURSE they'll get
  3374. something that looks different!  Who could expect anything else?  If the
  3375. designer returned with something the same as the existing de-facto standard
  3376. he would be a braver man than most.  Hell, they could have saved hard $$$
  3377. by buying Infinity Windoid from Troy Gual.
  3378.  
  3379. The sticky note windows are even more bothersome.  As is the inclusion of
  3380. single-click to launch in the Launcher palette.  I've found that it takes
  3381. users time to learn the double click to launch method in the Finder, but
  3382. once they do, they understand it.  Now, IN THE SAME PROGRAM, there are
  3383. _two_ methods to open files.  This is good?
  3384.  
  3385. Looking farther into the future, does the pre-emption of the "File" menu
  3386. with a "Document" menu in OpenDoc bother anyone?  This seems to me to be
  3387. a gratuitous market decision in a vain attempt to differentiate" OpenDoc
  3388. from the current crop of applications.  Hogwash.  Changing the name of
  3389. "File" to "Document" only confuses people, takes up menu bar space, and
  3390. will NOT increase market share one tiny bit.  Do users a vavor, dump the
  3391. "Document" menu and the old, expected and unsuprising "File".
  3392.  
  3393. Consistancy and the route of least suprise are _very_ important principles
  3394. and I wish that stupid columnists would quit harping about the "tired old
  3395. Mac interface".  An interface _should_ be "boring" and "underwhelming".
  3396. It should not overwhelm the functionality of the system.  It should be
  3397. as invisible as possible.  Since computer interfaces are definately not
  3398. intuative, only through consistancy will we even approach the goal of
  3399. invisibility.
  3400.  
  3401. If people want funky looking buttons and windows, third party options
  3402. exist.  But at least most third party options work over all applications,
  3403. thus still providing some consistancy on that single machine.
  3404.  
  3405. Finally, lest anyone say that these issues should have been brought up
  3406. long ago...they were.  Both here, on AppleLink and probably other on-line
  3407. services as well.
  3408.  
  3409. Cheers,
  3410. Rob
  3411. _____________________________________________________________________
  3412. Robert S. Mah           Software Development          +1.212.947.6507
  3413. One Step Beyond        and Network Consulting          rmah@panix.com
  3414.  
  3415. +++++++++++++++++++++++++++
  3416.  
  3417. >From andrew@csgrad.cs.vt.edu (Andrew Southwick)
  3418. Date: 19 Aug 1994 14:34:06 GMT
  3419. Organization: IBM SWSD, Lexington, KY, USA
  3420.  
  3421. wysocki@netcom.com (Chris Wysocki) writes:
  3422. >David John Burrowes <netcom.com!kira!davidjohn> wrote:
  3423.  
  3424. >>I find myself concerned, therefore, with all of these new innovations.
  3425.  
  3426. These new interface elements are truly surprising, since they haven't
  3427. implemented all the stuff that they should have - see below.
  3428.  
  3429. >....  Their reluctance
  3430. >to provide standard implementations of UI features such as floating
  3431. >windows, menus with multiple-modifier keyboard shortcuts, and basic
  3432. >controls such as up-down arrows,
  3433.  
  3434. "spinners", such as for the Time field in what used to be known as the
  3435. General control panel?
  3436.  
  3437. >sliders and progress bars have forced
  3438. >developers to implement these features themselves, with varying and
  3439. >sometimes inconsistent results.
  3440.  
  3441. This really (constantly) surprises me.  THIS is the part of the human
  3442. interface that APPLE should be working on.  Why do I have to create
  3443. all these controls by hand?  Why has Apple refused to develop these
  3444. interface enhancements?  They recognize that (at least some) of them
  3445. are needed, and Apple products use almost all of these (multiple-
  3446. modifiers being the one exception, correct me if you've found an Apple
  3447. product that does use them) interface methods themselves.
  3448.  
  3449. >At the Worldwide Developers
  3450. >Conference in May some Apple engineers spoke in nebulous terms about
  3451. >future UI enhancements which are coming down the road, but it struck
  3452. >me and others with whom I spoke as too little, too late....
  3453.  
  3454. I'd like to confront some Apple management types about this stuff, but
  3455. given that it's not likely, I thought I'd vent my spleen here.
  3456.  
  3457. >Chris.
  3458.  
  3459. Another poster mentions MotU's Performer - which I've seen and used (for
  3460. 9 months or so).  It's something you get used to - but why should I
  3461. change my methods at all?  I use Opcode's Vision, which has a more Mac-like
  3462. interface.  It does use drop-down menus in windows.  More like pop-ups,
  3463. actually.  They drop down from icons - but the icons have drop shadows.
  3464. A more consistent Mac-like interface, and rather than being 'artsy' to
  3465. appeal to (what? I have no idea), it's just a plain, simple, boring,
  3466. underwhelming, IGNORABLE interface.  You get on with your work, because you
  3467. don't have to think about the interface!
  3468.  
  3469. As far as changing interface elements: tools like QuickChange allow users
  3470. to affect interface elements at their leisure.  I use 3D buttons, check
  3471. boxes, and radio buttons.  What annoys me is those apps that bypass
  3472. the Toolbox calls to use these things - or use different background or
  3473. foreground colors, such that my (new) controls contrast sharply with
  3474. whatever's in the menus.  I can just imagine how confusing 6 more button
  3475. types and 6 more window types will be, especially with the 3 more that
  3476. I (an end user) add myself.
  3477.  
  3478. Apple, catch a clue.  Please.
  3479.  
  3480.  
  3481. Best Premises,                                      andrew@csgrad.cs.vt.edu
  3482. Andrew R. Southwick                                 asouthwick@vnet.ibm.com
  3483.  
  3484.  
  3485. +++++++++++++++++++++++++++
  3486.  
  3487. >From gurgle@dnai.com (Pete Gontier)
  3488. Date: Fri, 19 Aug 1994 10:23:50 -0800
  3489. Organization: Integer Poet Software
  3490.  
  3491. In article <rmah-1908940819170001@rmah.dialup.access.net>, rmah@panix.com
  3492. (Robert Mah) wrote:
  3493.  
  3494. > Consistancy and the route of least suprise are _very_ important principles
  3495. > and I wish that stupid columnists would quit harping about the "tired old
  3496. > Mac interface".  An interface _should_ be "boring" and "underwhelming".
  3497. > It should not overwhelm the functionality of the system.  It should be
  3498. > as invisible as possible.  Since computer interfaces are definately not
  3499. > intuative, only through consistancy will we even approach the goal of
  3500. > invisibility.
  3501.  
  3502. I don't know about your experience, but in mine I have found that the
  3503. columnists who say this are usually Intel columnists. By that I don't mean
  3504. they work for Intel directly, but that they write about Windows or OS/2 or
  3505. perhaps even DOS. The phrase I see most is "The Macintosh interface is
  3506. showing signs of its age." The thing that's ironic about it is that the
  3507. Windows interface, a blatant copy, is basically just as old, even though
  3508. it started out radically different (and of course much much worse, but
  3509. that's a different problem). I'm not really sure what the columnists are
  3510. trying to get at, other than the fact that the Mac interface doesn't
  3511. change. That's the whole point. The Windows interface changes whenever
  3512. some jokers like Borland decide to throw in *even more* interface elements
  3513. differentiated only by color and *even more* mysterious icons decodable
  3514. only by Westerners and sometimes even only by Americans. These columnists
  3515. were weaned on DOS, where every app had a new interface. So when most
  3516. every Windows app has some new interface element for which one must read
  3517. the docs, they cope. And then they complain that the Mac interface is
  3518. "getting old" because they don't have to cope so much or so often.
  3519.  
  3520. It seems like one or a combination of the below things is happening.
  3521.  
  3522.    (1) Apple Marketing reads these columnists and figures they must know
  3523.        what they're talking about.
  3524.    (2) The market reads these columnists, figures they must know what
  3525.        they're talking about, and tells Apple Marketing, who in turn
  3526.        thinks it has no alternative but to respond.
  3527.    (3) More and more non-Macintosh engineers are getting hired at Apple
  3528.        and there's nobody left to brainwash them properly.
  3529.  
  3530. Frankly, from what I've seen of System 7.5, there's less and less reason
  3531. to develop for Macintosh. That ought to scare the shit out of Apple,
  3532. because the only way they'll survive is if people think there's reason to
  3533. bother.
  3534.  
  3535. -- 
  3536.  Pete Gontier // CTO, Integer Poet Software // gurgle@dnai.com
  3537.  
  3538.  "Even during a particularly harsh (Colorado) winter... many of the
  3539.  300 families in the VCTV (movies-on-demand) trial continued to go
  3540.  to video stores." -- eis@murrow.tufts.edu, in Wired 2.09 p62
  3541.  
  3542. +++++++++++++++++++++++++++
  3543.  
  3544. >From gurgle@dnai.com (Pete Gontier)
  3545. Date: Fri, 19 Aug 1994 10:28:35 -0800
  3546. Organization: Integer Poet Software
  3547.  
  3548. In article <332fsu$v0o@watnews1.watson.ibm.com>, andrew@csgrad.cs.vt.edu wrote:
  3549.  
  3550. > Why has Apple refused to develop these
  3551. > interface enhancements?  They recognize that (at least some) of them
  3552. > are needed, and Apple products use almost all of these (multiple-
  3553. > modifiers being the one exception, correct me if you've found an Apple
  3554. > product that does use them) interface methods themselves.
  3555.  
  3556. I don't think "refused" is quite the right word. I think what's going on
  3557. is that Apple is a disgusting fragmented byzantine re-organized
  3558. bureaucracy at this point. Nobody has the authority to put their foot down
  3559. and say "dammit, add floating window support to the Window Manager". Lots
  3560. of people can produce paperwork showing why it should wait until next year
  3561. when the Frobozzination Manager comes out. But nobody can put their foot
  3562. down.
  3563.  
  3564. -- 
  3565.  Pete Gontier // CTO, Integer Poet Software // gurgle@dnai.com
  3566.  
  3567.  "Even during a particularly harsh (Colorado) winter... many of the
  3568.  300 families in the VCTV (movies-on-demand) trial continued to go
  3569.  to video stores." -- eis@murrow.tufts.edu, in Wired 2.09 p62
  3570.  
  3571. +++++++++++++++++++++++++++
  3572.  
  3573. >From gurgle@dnai.com (Pete Gontier)
  3574. Date: Fri, 19 Aug 1994 10:32:17 -0800
  3575. Organization: Integer Poet Software
  3576.  
  3577. In article <1994Aug19.031720.1465@kira.net.netcom.com>,
  3578. netcom.com!kira!davidjohn (David John Burrowes) wrote:
  3579.  
  3580. > But, with Microsoft coming  
  3581. > out with a significantly improved user interface for Windows soon (Chicago),  
  3582. > this all strikes me as Apple shooting itself in the foot...
  3583.  
  3584. Don't worry about Chicago's interface. Windows programmers are too
  3585. "creative" to let Microsoft get away with imposing an interface standard.
  3586. Not that Microsoft's choices would be any good. I'm more concerned that
  3587. Apple is giving eveything away by failing to internally impose standards
  3588. they worked so hard to establish.
  3589.  
  3590. -- 
  3591.  Pete Gontier // CTO, Integer Poet Software // gurgle@dnai.com
  3592.  
  3593.  "Even during a particularly harsh (Colorado) winter... many of the
  3594.  300 families in the VCTV (movies-on-demand) trial continued to go
  3595.  to video stores." -- eis@murrow.tufts.edu, in Wired 2.09 p62
  3596.  
  3597. +++++++++++++++++++++++++++
  3598.  
  3599. >From kanderso@mabillon.ICS.UCI.EDU (Ken Anderson)
  3600. Date: 19 Aug 94 18:05:20 GMT
  3601. Organization: (none)
  3602.  
  3603. >One would expect that with Don Norman in charge (he is in charge of HIG
  3604. >isn't he?) that HIG would be less worried over the "look" and more about
  3605. >the "feel".
  3606.  
  3607. Don Norman is an Apple Fellow and is in charge of the Personal
  3608. Digital Assistants group. The first product from that group was of
  3609. course the Newton.
  3610.  
  3611. The person in charge of the Human Interface group is I belive Joy Mountford,
  3612. who gave a really snazzy talk at Boston last April at CHI94.
  3613.  
  3614. FYI,
  3615.  
  3616. Ken
  3617. --
  3618. - ------------------------------------------------------------------------------
  3619. -Ken Anderson            Ken_Anderson@acm.org                       U.C. Irvine-
  3620. - "A knowledge of C is probably better than nothing." -- J.G.P. Barnes         -
  3621. -                 Finger kanderso@ics.uci.edu for PGP Public Key               -
  3622. - ------------------------------------------------------------------------------
  3623.  
  3624. +++++++++++++++++++++++++++
  3625.  
  3626. >From shebs@cygnus.com (Stan Shebs)
  3627. Date: Fri, 19 Aug 1994 18:48:18 GMT
  3628. Organization: /cygint/s1/users/shebs/.organization
  3629.  
  3630.  
  3631. In article <rmah-1908940819170001@rmah.dialup.access.net> rmah@panix.com (Robert Mah) writes:
  3632.  
  3633.    I wholeheartedly concur.  Apple's HIG seems to have lost its way -- either
  3634.    that or they have lost their authority to override developer's and 
  3635.    designers taste for the strange.  One would expect that with Don Norman in
  3636.    charge (he is in charge of HIG isn't he?) that HIG would be less worried
  3637.    over the "look" and more about the "feel".  That they would hire fewer
  3638.    graphic designers and more people versed in psychology and sociology.
  3639.  
  3640. Last I heard, Don Norman was just a researcher in ATG, and was not in
  3641. charge of any actual product work.  The only HI-related product person
  3642. I've talked to recently had just left Apple...
  3643.  
  3644. One of the functions of the Blue Meanies was to balance the desires of
  3645. internal developers and designers against the need for compatibility.
  3646. An Architect with real authority would do this kind of thing also.
  3647. Alas, Apple seems not to have either these days...
  3648.  
  3649.                             Stan Shebs
  3650.                             Cygnus Support
  3651.                             shebs@cygnus.com
  3652.  
  3653.  
  3654. +++++++++++++++++++++++++++
  3655.  
  3656. >From rob@eats.com (Rob Newberry)
  3657. Date: Fri, 19 Aug 1994 15:17:28 UNDEFINED
  3658. Organization: Education and Technology Solutions
  3659.  
  3660. Well, I can't tell if I agree or disagree with the others in this thread.  But 
  3661. in some ways, I'm quite sure I favor enhancements to the user interface.  In 
  3662. my opinion, many things in the interface need to evolve.  I am terribly 
  3663. excited about the new things in System 7.5.
  3664.  
  3665. As I understand it, Apple is readying a new Appearance Manager, which will 
  3666. let the user customize much of the interface.  I think this is a "good thing". 
  3667. I'm sure it will come with a "default", but I like the idea of being able to 
  3668. take control.
  3669.  
  3670. On the other hand, as a programmer, if I gave up on Apple already, and started 
  3671. trying to implement my own 3D buttons or the like, what will happen when 
  3672. Appearance Manager comes out?  Will the user be able to customize every 
  3673. application (oh, yeah, by then, my app won't be an app, but an OpenDoc 
  3674. "document manager") except mine?  Yikes!
  3675.  
  3676. In short, I wish Apple had loosened the reigns a little more earlier.  Though 
  3677. I don't think they're far behind in the standard look and feel, a lot of 
  3678. developers have moved on and done things that needed to be done on their own.
  3679.  
  3680. Rob
  3681.  
  3682.  
  3683.  
  3684. +++++++++++++++++++++++++++
  3685.  
  3686. >From dnebing@andy.bgsu.edu (bgsuvax)
  3687. Date: 19 Aug 1994 19:41:27 GMT
  3688. Organization: Bowling Green State University
  3689.  
  3690.   Where have the standards gone?  Out the window.  But that's
  3691. been a long time coming.
  3692.  
  3693.   Standards are good if they are robust and evolve with change.
  3694. However the HIG standard, while at first introduction was quite
  3695. robust, didn't keep up with what was being published in the
  3696. industry.
  3697.  
  3698.   Take for example Word's toolbar that can be found in most of
  3699. their apps now and can also be found in other vendor's apps
  3700. (i.e. CodeWarrior).  The HIGs never evolved to encompass
  3701. toolbars, hence the thread that started here some time back
  3702. about toolbar icons representing nouns or verbs, and which
  3703. was appropriate.
  3704.  
  3705.   There has always been things that we, as Mac programmers,
  3706. have wanted to do but were limited by the HIGs.  So the
  3707. choice between following the guidelines or throwing the
  3708. HIGs out the window and just do what was necessary.
  3709.  
  3710.   While most programmers have followed the guidelines, there
  3711. are several apps out there that have had to break the HIGs
  3712. in order to do what was necessary.
  3713.  
  3714.   If the HIGs are dead, then RIP.  If not, then the HIG
  3715. people at Apple have some major work to do to bring the HIGs
  3716. up to snuff with respect to new interface elements and then
  3717. coerce us (the programmers) that the HIGs are worth following.
  3718.  
  3719. Dave
  3720.  
  3721. ============================================================
  3722. Dave Nebinger                    dnebing@bgsuvax.bgsu.edu
  3723. Network Manager, Biology Dept.   dnebing@opie.bgsu.edu
  3724. Bowling Green State University   dnebing@bgsuopie (bitnet)
  3725. Bowling Green, OH 43403          #include <std_disclaimer.h>
  3726.  
  3727.              *THE* alt.sources.mac supporter!
  3728.  
  3729. +++++++++++++++++++++++++++
  3730.  
  3731. >From h+@nada.kth.se (Jon W{tte)
  3732. Date: Fri, 19 Aug 1994 22:27:27 +0200
  3733. Organization: Royal Institute of Something or other
  3734.  
  3735. In article <1994Aug19.031720.1465@kira.net.netcom.com>,
  3736. netcom.com!kira!davidjohn (David John Burrowes) wrote:
  3737.  
  3738. >- a strange little thing for 'post-it' notes
  3739. >- a green one for the CD player (the title bar is similar to the standard
  3740. >  document titlebar, but not the same)
  3741.  
  3742. These are specialized apps that don't use standard documents, 
  3743. and as such are entitled to having their own user interface, 
  3744. sort of. The more they go in with the Mac look, the better; and 
  3745. both of these can have the window colors set to white.
  3746.  
  3747. >- the Find File windows have a funky styled background
  3748.  
  3749. It's funky in the betas, where's its a structured noise 
  3750. pattern; in the release it's just a kind of subtle weave that I 
  3751. don't like half as much. I pasted back the gray pattern from 
  3752. the betas :-)
  3753.  
  3754. That pattern is available from the system file (ID=42) for 
  3755. anyone who wants a gray background, presumably.
  3756.  
  3757. >- A window that is reminiscent of the 'palette' titlebar, but with close
  3758. >  and zoom boxes.
  3759.  
  3760. Yeah, but that's the new floating window WDEF that Apple wants 
  3761. ALL of us to use; i e it's a STANDARD as opposed to all the 
  3762. variants of floating palettes we've seen now.
  3763.  
  3764. However, I have this feeling people are not going to use this 
  3765. floating WDEF, since the title bar is too bloody large for most 
  3766. floating pallette uses - Apple says that's to make it easier to 
  3767. hit for newbies, but to me, that seems less important than real 
  3768. productivity for real users...
  3769.  
  3770. Cheers,
  3771.  
  3772.                 / h+
  3773.  
  3774.  
  3775. --
  3776.   Jon W‰tte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden
  3777.  
  3778. "TextEdit does everything right."
  3779.     ã Jon W{tte
  3780.  
  3781.  
  3782. +++++++++++++++++++++++++++
  3783.  
  3784. >From sanford@CS.Arizona.EDU (Sanford H. Selznick)
  3785. Date: 19 Aug 1994 17:58:35 -0700
  3786. Organization: University of Arizona CS Department, Tucson AZ
  3787.  
  3788. Why did Apple change it's UI so drastically in 7.5?  Marketing.  When
  3789. Joe computer buyer walks into a Sears or BizMart he's going to see two
  3790. computers.  He'll see a 486 box running windows 3.1 and a Mac running
  3791. system 7.1.  
  3792.  
  3793. The 486 will undoubtedly have the calculator open.  And, well, at
  3794. first glance it looks darned good.  It's got that electric grey 
  3795. background, 3D buttons, and it's big.  Is this something you'd want to
  3796. use every day?  No way.
  3797.  
  3798. The Mac will undoubtedly have the trash window open.  The trash icon will be
  3799. sitting in the middle of the screen.  So the sales rep says "the mac
  3800. has a calculator too."  And what does it look like?  A small blue
  3801. piece of crap that obviously hasn't evolved as fast as the windows
  3802. calculator.  It just doesn't look as good.
  3803.  
  3804. Before I go on, let me say I've been 1000% more productive on my mac
  3805. than I have been on a 486 box running windows.  I like the mac
  3806. calculator better too.  But when it comes time to sell a machine to
  3807. Joe Shmo, he wants to see that electric grey calculator.
  3808.  
  3809. Of course the graphic calculator that comes with the PPC blows
  3810. everything else away... and that's a step in the right direction.  Not
  3811. funky post-its.  
  3812.  
  3813. IMHO,
  3814.   Sanford
  3815.  
  3816. +++++++++++++++++++++++++++
  3817.  
  3818. >From gurgle@dnai.com (Pete Gontier)
  3819. Date: Fri, 19 Aug 1994 19:43:47 -0800
  3820. Organization: Integer Poet Software
  3821.  
  3822. In article <rob.311.018B2E0E@eats.com>, rob@eats.com (Rob Newberry) wrote:
  3823.  
  3824. > As I understand it, Apple is readying a new Appearance Manager, which will 
  3825. > let the user customize much of the interface.  I think this is a "good
  3826. thing". 
  3827. > I'm sure it will come with a "default", but I like the idea of being able to 
  3828. > take control.
  3829.  
  3830. This is a Really Bad Thing, IMO. Sure, Windows has it. So what? Windows
  3831. has a SYSTEM.INI, too. Suddenly you're going to have every half-baked
  3832. ResEdit jockey creating new Appearances, and co-workers are going to be
  3833. confused by each other's machines. It's only a matter of time before the
  3834. Control Panel interface is replaced by a text file, I guess.
  3835.  
  3836. > Though I don't think (Apple is) far behind in the standard look and feel...
  3837.  
  3838. Apple *is* the standard look and feel. It's the other vendors who've gone
  3839. off into the weeds. Some (collective) genius at Apple now thinks it's a
  3840. good idea to follow them there.
  3841.  
  3842. -- 
  3843.  Pete Gontier // CTO, Integer Poet Software // gurgle@dnai.com
  3844.  
  3845.  "Even during a particularly harsh (Colorado) winter... many of the
  3846.  300 families in the VCTV (movies-on-demand) trial continued to go
  3847.  to video stores." -- eis@murrow.tufts.edu, in Wired 2.09 p62
  3848.  
  3849. +++++++++++++++++++++++++++
  3850.  
  3851. >From gurgle@dnai.com (Pete Gontier)
  3852. Date: Fri, 19 Aug 1994 19:49:00 -0800
  3853. Organization: Integer Poet Software
  3854.  
  3855. In article <3331t7$rc8@falcon.bgsu.edu>, dnebing@andy.bgsu.edu (bgsuvax) wrote:
  3856.  
  3857. > ...the HIG standard, while at first introduction was quite
  3858. > robust, didn't keep up with what was being published in the
  3859. > industry. Take for example Word's toolbar ...
  3860.  
  3861. My God, the day has come to kill myself. Someone is seriously referring to
  3862. a Microsoft product as having a good interface.
  3863.  
  3864. To be a little less histionic, the ToolBar(tm) is the worst thing to
  3865. happen to interface in a long time, IMO. It's all well and good to have
  3866. clickable icons represent metaphorical paint tools, but when it comes to
  3867. down to saving a file, there's no good icon. But Microsoft didn't let a
  3868. little detail like *that* stop them. After all, 30 people at Microsoft
  3869. thought it was a good idea -- who else counts?
  3870.  
  3871. > While most programmers have followed the guidelines, there
  3872. > are several apps out there that have had to break the HIGs
  3873. > in order to do what was necessary.
  3874.  
  3875. Examples being?
  3876.  
  3877. -- 
  3878.  Pete Gontier // CTO, Integer Poet Software // gurgle@dnai.com
  3879.  
  3880.  "Even during a particularly harsh (Colorado) winter... many of the
  3881.  300 families in the VCTV (movies-on-demand) trial continued to go
  3882.  to video stores." -- eis@murrow.tufts.edu, in Wired 2.09 p62
  3883.  
  3884. +++++++++++++++++++++++++++
  3885.  
  3886. >From gurgle@dnai.com (Pete Gontier)
  3887. Date: Fri, 19 Aug 1994 21:25:17 -0800
  3888. Organization: Integer Poet Software
  3889.  
  3890. In article <gurgle-1908941949000001@gurgle.dnai.com>, gurgle@dnai.com
  3891. (Pete Gontier) wrote:
  3892.  
  3893. > To be a little less histionic
  3894.  
  3895. Don'tcha just hate it when you use a 50 cent word and typo it?
  3896.  
  3897. -- 
  3898.  Pete Gontier // CTO, Integer Poet Software // gurgle@dnai.com
  3899.  
  3900.  "Even during a particularly harsh (Colorado) winter... many of the
  3901.  300 families in the VCTV (movies-on-demand) trial continued to go
  3902.  to video stores." -- eis@murrow.tufts.edu, in Wired 2.09 p62
  3903.  
  3904. +++++++++++++++++++++++++++
  3905.  
  3906. >From 103t_english@west.cscwc.pima.edu
  3907. Date: 19 Aug 94 21:57:03 MST
  3908. Organization: (none)
  3909.  
  3910. In article <1994Aug19.031720.1465@kira.net.netcom.com>, netcom.com!kira!davidjohn (David John Burrowes) writes:
  3911. > I was reading the article about System 7.5 in the September 1994 issue of  
  3912. > MacUser (p. 79-84), and it raised a gigantic question in my mind.  After  
  3913. > some thought, I decided to see what opinions others (yourselves) might have.
  3914. > The 'screenshots' on pages 80-81 and 82-83 of the above issue shows several  
  3915. > new features of this system software release.  In them, I noted five new  
  3916. > window styles:
  3917.  
  3918. [examples of inconsistant interface and ruminations on the subject snipt]
  3919.  
  3920. > If you've read this far, I'm curious what your thoughts are, either through  
  3921. > personal email or on the newsgroup.  Maybe I'm very much in the minority,  
  3922. > and folks generally think the 'highly consistent' interface was too  
  3923. > constraining?
  3924.  
  3925. I think that it is obvious that 7.5 is a rush-job. Aside from AppleScript,
  3926. AOCE, GX nad one or two other exceptions, the new stuff in 7.5 all appears to
  3927. be licensed from 3rd parties and included as is without any attempt to make it
  3928. more System 7-ish.
  3929.  
  3930. It ain't that impressive from an HI or integrated-design standpoint, but it 
  3931. DOES add needed functionality.
  3932.  
  3933.  
  3934. Maybe the 7.8 upgrade will address these issues?
  3935.  
  3936.  
  3937. Lawson
  3938.  
  3939. +++++++++++++++++++++++++++
  3940.  
  3941. >From L.H.Wood@student.lut.ac.uk
  3942. Date: Fri, 19 Aug 1994 13:58:07 GMT
  3943. Organization: Loughborough University, UK.
  3944.  
  3945. In article <pcastine-1908941211190001@maggie.prz.tu-berlin.de> pcastine@prz.tu-berlin.de (Peter Castine) writes:
  3946. >In article <1994Aug19.031720.1465@kira.net.netcom.com>,
  3947. >netcom.com!kira!davidjohn (David John Burrowes) wrote:
  3948. >
  3949. >> I was reading the article about System 7.5 in the September 1994 issue of  
  3950. >> MacUser (p. 79-84), and it raised a gigantic question in my mind.  After  
  3951. >> some thought, I decided to see what opinions others (yourselves) might have.
  3952. >> 
  3953. >> The 'screenshots' on pages 80-81 and 82-83 of the above issue shows several  
  3954. >> new features of this system software release.  In them, I noted five new  
  3955. >> window styles:
  3956. >
  3957. >[schnipp...]
  3958. >
  3959. >> If you've read this far, I'm curious what your thoughts are, either through  
  3960. >> personal email or on the newsgroup.  Maybe I'm very much in the minority,  
  3961. >> and folks generally think the 'highly consistent' interface was too  
  3962. >> constraining?
  3963. >
  3964. The new mini-window bar is generally considered ugly, and generated a lot
  3965. of discussion in csmp.
  3966.  
  3967. [..]
  3968. >It seems to me that standards are going out the window, and that this is a
  3969. >negative development. Conventional buttons and WDEFs may seem a little
  3970. >unadventurous, but in day-to-day work the security of knowing how to
  3971. >recognize a button and where the window title is are a great advantage. I
  3972. >always disliked HyperCard's anything-can-be-a-button attitude, because it
  3973. >leaves you with the challenge of clicking on *everything*, just to see if
  3974. >maybe that little chicklet-shaped object triggers some sort of action.
  3975. >This is fine and dandy for an adventure game, but frustrating when you're
  3976. >trying to get on with your work.
  3977. >
  3978. >As one example, I was looking at the new(ish) AppleCD Audio Player. The
  3979. >only reason I even tried clicking on the little green triangle in the
  3980. >lower left corner was because I knew that the fore-runner software had a
  3981. >track list and I was sure that the newer software _must_ have a track list
  3982. >somewhere. I looked in the menus, to no avail, so I started clicking
  3983. >around and the mouse finally landed on said triangle. Voila! Success at
  3984. >last!
  3985. >
  3986. >But, why the hell should I spend my time clicking around a window to find
  3987. >a substitute for the Zoom box? (Use of the zoom box as a sort of
  3988. >{show|hide}-details-of-a-dialog-window is not officially sanctioned, but
  3989. >has found it's way into a number of utility programs). Sure, if I'd turned
  3990. >on Balloon Help, I might have found this button sooner, but an experienced
  3991. >Mac user shouldn't need Balloon Help to find an _Ersatz_ zoom box.
  3992. >
  3993. I think of these as 'Easter Eggs', which I dislike. If a tool surprises me
  3994. (and a computer is a tool) then it's not transparent to me, which means
  3995. it's badly designed.
  3996.  
  3997. >That said, let me add that it *is* important for UIs to develop; I'm not
  3998. >going to advocate cast-in-platinum Human Interface Guidelines. The
  3999. >_Macintosh Humand Interface Guidelines_ discuss the subject of ``Going
  4000. >Beyond the Guidelines'' quite specifically. 
  4001. >
  4002. >The problem with System 7.5 seems to be that Apple has simply integrated a
  4003. >couple of 3rd party extensions where graphic design went out of control,
  4004. >and nobody bothered to talk with Human Interface about what was good, bad,
  4005. >or useful. 
  4006. >
  4007. Didn't Apple sack most of Human Interface a while back, on the grounds that
  4008. they needed the redundancies and human-interface people don't generate money?
  4009.  
  4010. [The number of applications rolling in different 3D buttons is annoying. I
  4011. don't like 3D buttons; I want consistent 2D buttons, not 3D buttons that
  4012. differ in every application.]
  4013.  
  4014. Quick question - how many human-interface people have ever worked for 
  4015. Microsoft?
  4016.  
  4017. This bothers me, a lot.
  4018.  
  4019. L.
  4020.  
  4021. -- 
  4022.  
  4023. _____________________________________________________________________________
  4024. L.H.Wood@student.lut.ac.uk     Email me for a copy of the Mac screensaver FAQ
  4025.  
  4026.  
  4027. +++++++++++++++++++++++++++
  4028.  
  4029. >From tgaul@halcyon.com (Troy Gaul)
  4030. Date: Sat, 20 Aug 1994 00:46:27 -0700
  4031. Organization: Infinity Systems
  4032.  
  4033. This discussion has brought up a lot of good points about the Bad Things
  4034. that are happening to the interface, particularly with System 7.5.
  4035.  
  4036. One point I'd like to make is that most of the things we're talking about
  4037. here aren't things that Apple _had_ to invent from scratch because there
  4038. weren't already prefectly good ways of doing them.  One of the things that
  4039. the HI people at Apple keep saying is to not invent new interface elements
  4040. when the ones that are available will suit the purpose.  (I'll expand this
  4041. to include that one shouldn't create new appearances for essentially the
  4042. same controls, as that effectively makes them into new controls.)
  4043.  
  4044.  
  4045. Back when System 7 first came out, I was really glad that they finally did
  4046. something about the black-and-white titlebars and scrollbars in windows. 
  4047. You will notice, however, that even though they added color and 3D
  4048. effects, they did so in a tasteful manner (IMHO).
  4049.  
  4050. This new look was what inspired me to write the Infinity Windoid WDEF, as
  4051. the old black-and-white WDEF of the past were just lacking something. 
  4052. When I first made it, however, I tried first and foremost to stay true to
  4053. the original design of floater WDEFs.  The size and position of the
  4054. gadgets were the same, and the coloring scheme matched that of the new
  4055. System 7 windows.  Although the height of the titlebar has grown 2 pixels
  4056. since this first version, I think it is still true to the earlier WDEF,
  4057. and I think that makes it easy for people to identify as a floater.
  4058.  
  4059. When I see the new Apple 7.5 titlebar, I instantly think 'Help Window',
  4060. because this is where it is seen most often.  Maybe this will change if
  4061. apps start using it for floaters, but I'm not sure.
  4062.  
  4063.  
  4064. As for the comments about the design of the new AppleCD Audio Player, I
  4065. don't find that as offensive as some of the other people who've commented
  4066. on it.  The main reason I feel this way is that this is what I'll call a
  4067. 'consumer interface' program (it's designed to look more like a 'real' CD
  4068. Player's control panel).  My main gripe is the triangle control.  Apple
  4069. has the 'turn knob' control like is used in the old Alarm Clock DA that
  4070. would has served the purpose without adding yet another new interface
  4071. element.  (But [sarcastic tone], of course that doesn't have any color in
  4072. it...)
  4073.  
  4074. The new application to control the 630's TV Tuner, if you look at it, has
  4075. an interface that is similar, as it is also a consumer-type controller.
  4076.  
  4077. Now, we have the post-it note application.  The reason for the window
  4078. design there is that the titlebar and grow box are attempting to stay out
  4079. of the way as much as possible, so that it looks like a post-it, even when
  4080. the titlebar is active.  I may not love the fact that the interface is
  4081. different, but I at least understand it, and since I never use it
  4082. anyway...
  4083.  
  4084. I'm not saying these changes are all good, by any means, but _some_ of
  4085. them are understandable (if they are kept in check).
  4086.  
  4087. As for the Find File application window, all I can say is that Apple has
  4088. given guidelines for a 3D beveled interface in a past issue of Develop
  4089. (where a 'flat' light gray is used as the main color).  Why couldn't they
  4090. just use this interface?  And similarly, the 3D icon-buttons described in
  4091. that article would work for the buttons in the help window (without the
  4092. edges being quite so thick, as they were at least in the beta).  Though, I
  4093. didn't like the alternate push buttons, radio buttons, and check boxes
  4094. given in that article.  Use the standard CDEF, darn it!...  If people want
  4095. gray standard buttons, they can install something like Greg's Buttons and
  4096. at least have it done consistently.
  4097.  
  4098. Oh, and don't forget that the AppleScript Script Editor and the PowerTalk
  4099. mailer, which both use something like the Develop-described beveled
  4100. interface, even seem to use different shades of gray for the main part of
  4101. the window(!).  I could go on, but I think I'm preaching to the choir
  4102. here.
  4103.  
  4104. Anyway, I'd like to hear from some of the Apple people who are on the list
  4105. as to how this stuff goes on.  How do these designs get into products?  I
  4106. understand that there was one person in particular who did most of the
  4107. designs for the color icons when System 7 was released, why isn't there a
  4108. similar person who could enforce some amount of user interface
  4109. consistency?
  4110.  
  4111. _troy
  4112. //////// //////___Troy Gaul____________________tgaul@halcyon.com___//
  4113.   //    //      Infinity Systems                                  //
  4114.  //    //  //  Redmond, Washington                               //
  4115. //    //////____________________________________________________//
  4116.  
  4117. +++++++++++++++++++++++++++
  4118.  
  4119. >From gasser@masg1.epfl.ch (Laurent Gasser)
  4120. Date: 20 Aug 1994 12:50:33 GMT
  4121. Organization: Ecole Polytechnique Federale de Lausanne
  4122.  
  4123. The Human Interface Guideline specifically ban the window toolbar as
  4124. too numerous icons.  (It is in the scroll bar chapter, if my memory 
  4125. is faithfull.  They show two windows, one with one or two additional 
  4126. functionality to scroll bar, the other, bad example looks like Word's 
  4127. windows.)  The spirit of Mac interface is quite stringent.  Remember 
  4128. the guidelines about the use of color?  Don't use it as the single 
  4129. way to convey information except when it is the whole information.
  4130.  
  4131. Basically, make the interface look simple, so simple it looks dumb.
  4132.  
  4133. Don't even do that: make it look sober!
  4134.  
  4135. In article <3331t7$rc8@falcon.bgsu.edu>, dnebing@andy.bgsu.edu (bgsuvax) writes:
  4136. [edited]
  4137. |>   Standards are good if they are robust and evolve with change.
  4138. |> However the HIG standard, while at first introduction was quite
  4139. |> robust, didn't keep up with what was being published in the
  4140. |> industry.
  4141. |> 
  4142. |>   Take for example Word's toolbar that can be found in most of
  4143. |> their apps now and can also be found in other vendor's apps
  4144. |> (i.e. CodeWarrior).  The HIGs never evolved to encompass
  4145. |> toolbars, hence the thread that started here some time back
  4146. |> about toolbar icons representing nouns or verbs, and which
  4147. |> was appropriate.
  4148. |> 
  4149. [edited]
  4150. |> Dave
  4151. |> 
  4152. |> ============================================================
  4153. |> Dave Nebinger                    dnebing@bgsuvax.bgsu.edu
  4154. |> Network Manager, Biology Dept.   dnebing@opie.bgsu.edu
  4155. |> Bowling Green State University   dnebing@bgsuopie (bitnet)
  4156. |> Bowling Green, OH 43403          #include <std_disclaimer.h>
  4157. |> 
  4158. |>              *THE* alt.sources.mac supporter!
  4159.  
  4160. -- 
  4161. Laurent Gasser (gasser@dma.epfl.ch)
  4162. Computers do not solve problems, they execute solutions.
  4163.  
  4164. I know very few ideas worth dying for, none is worth killing.
  4165.  
  4166. +++++++++++++++++++++++++++
  4167.  
  4168. >From rmah@panix.com (Robert Mah)
  4169. Date: Sat, 20 Aug 1994 09:09:14 -0500
  4170. Organization: One Step Beyond
  4171.  
  4172. gurgle@dnai.com (Pete Gontier) wrote:
  4173.  
  4174. ) rmah@panix.com (Robert Mah) wrote:
  4175. ) > Consistancy and the route of least suprise are _very_ important
  4176. ) > principles and I wish that stupid columnists would quit harping
  4177. ) > about the "tired old Mac interface".  An interface _should_ be
  4178. ) > ...
  4179. ) I don't know about your experience, but in mine I have found that the
  4180. ) columnists who say this are usually Intel columnists. By that I don't
  4181. ) mean they work for Intel directly, but that they write about Windows
  4182. ) or OS/2 or perhaps even DOS. The phrase I see most is "The Macintosh
  4183.  
  4184. Umm, well I have seen the Mac rags talk about this, but whatever, my 
  4185. statement was a low blow and most journalists didn't deserve it.  Even
  4186. if they _do_ say, what I attributed to them, that certainly doesn't mak
  4187. them "stupid".   I appologize to any who may be listening in.
  4188.  
  4189. Cheers,
  4190. Rob
  4191. _____________________________________________________________________
  4192. Robert S. Mah           Software Development          +1.212.947.6507
  4193. One Step Beyond        and Network Consulting          rmah@panix.com
  4194.  
  4195. +++++++++++++++++++++++++++
  4196.  
  4197. >From rmah@panix.com (Robert Mah)
  4198. Date: Sat, 20 Aug 1994 09:26:38 -0500
  4199. Organization: One Step Beyond
  4200.  
  4201. rob@eats.com (Rob Newberry) wrote:
  4202.  
  4203. ) But in some ways, I'm quite sure I favor enhancements to the user
  4204. ) interface.  In my opinion, many things in the interface need to evolve.
  4205.  
  4206. Just like steering wheels and typewriters, huh?  Seriouslly, techies have
  4207. a love of the new and always want change.  Change, for no good reason, 
  4208. however, is anethma to a good human interface.  Again, the goals are
  4209. invisibility and no supprise.  Obviouslly, these cannot be reached, but
  4210. we can try to get closer by maintaining consistancy.
  4211.  
  4212. When research shows, conclusively that some interface element is out of
  4213. whack and needs change, then I'm all for it.  However, the change should
  4214. be made with respect to the existing system.
  4215.  
  4216. For example, Apple folk have said that research showed that normal float-
  4217. ing window move bars were too small.  OK, fine, we should make them bigger.
  4218. BUT, there is already a de-facto standard for their look (i.e. 50% gray
  4219. lines seperated by 1 pixel of background).  Why diverge from it?  There is
  4220. NO sound human interface or technical reason.
  4221.  
  4222.  
  4223. ) As I understand it, Apple is readying a new Appearance Manager, which
  4224. ) will let the user customize much of the interface.  I think this is a
  4225. ) "good thing".  I'm sure it will come with a "default", but I like the
  4226. ) idea of being able to take control.
  4227.  
  4228. Control is fine.  Customization is fine.  But ONLY after one has mastered
  4229. the basics.  And by rolling such a feature into the basic OS, as someone
  4230. else mentioned, one assures that inexperienced users will change the look
  4231. of their machines. 
  4232.  
  4233. This is not good.  They will only get confused when they have to use some-
  4234. one else's machine.  They will call tech support lines and complain that
  4235. the pictures in the manual don't match what they see on their computer.
  4236. In general, the interface will become an obstical instead of an aid.
  4237.  
  4238.  
  4239. ) In short, I wish Apple had loosened the reigns a little more earlier. 
  4240. ) Though I don't think they're far behind in the standard look and feel,
  4241. ) a lot of developers have moved on and done things that needed to be
  4242. ) done on their own.
  4243.  
  4244. But that's _part_ of the "official" guidelines.  If there is no accept-
  4245. able standard interface element that fits, create something new that
  4246. does.  Just make sure you consider the standard and de-facto standard
  4247. elements first.
  4248.  
  4249. Cheers,
  4250. Rob
  4251. _____________________________________________________________________
  4252. Robert S. Mah           Software Development          +1.212.947.6507
  4253. One Step Beyond        and Network Consulting          rmah@panix.com
  4254.  
  4255. +++++++++++++++++++++++++++
  4256.  
  4257. >From rmah@panix.com (Robert Mah)
  4258. Date: Sat, 20 Aug 1994 09:36:11 -0500
  4259. Organization: One Step Beyond
  4260.  
  4261. h+@nada.kth.se (Jon W{tte) wrote:
  4262.  
  4263. ) netcom.com!kira!davidjohn (David John Burrowes) wrote:
  4264. ) >- a strange little thing for 'post-it' notes
  4265. ) >- a green one for the CD player (the title bar is similar to the standard
  4266. ) >  document titlebar, but not the same)
  4267. ) These are specialized apps that don't use standard documents, 
  4268. ) and as such are entitled to having their own user interface, 
  4269. ) sort of. The more they go in with the Mac look, the better; and 
  4270. ) both of these can have the window colors set to white.
  4271.  
  4272. I disagree.  The CD-Player controls an external device with a small
  4273. number of discrete controls.  While its similarity to "real world"
  4274. CD players could be argued, I must point out that _my_ real CD player
  4275. looks nothing at all like the software CD-Player.  Actually, now
  4276. that I think about it, very few real CD-players look like that 
  4277. program's main window.
  4278.  
  4279. As for the Post-It (r) notes software.   Give me a break.  It's just a
  4280. bunch of windows for jotting quick notes that remember their locations.
  4281. I'm not denigrating the app, it's quite nicely done, but really...user
  4282. selectable color backgrounds would have been OK, but no standard (or
  4283. even miniature) grow box, etc., etc.  There's no excuse except ego 
  4284. gratification.
  4285.  
  4286.  
  4287. ) Yeah, but that's the new floating window WDEF that Apple wants ALL of
  4288. ) us to use; i e it's a STANDARD as opposed to all the variants of float-
  4289. ) ing palettes we've seen now.
  4290.  
  4291. What "varients" ?.  Except for a few apps that use the standard WDEF for
  4292. their floaters, they all look very similar (other than the use of color).
  4293. Only Apple's looks different.  They are the varient, the one at odds with
  4294. the de-facto standard that has emerged over the last few years.
  4295.  
  4296. If Apple had simply bought Troy's Infinity Windoid, everyone would have
  4297. been better off.  Especially the users (even if they wouldn't know it).
  4298.  
  4299. Cheers,
  4300. Rob
  4301. _____________________________________________________________________
  4302. Robert S. Mah           Software Development          +1.212.947.6507
  4303. One Step Beyond        and Network Consulting          rmah@panix.com
  4304.  
  4305. +++++++++++++++++++++++++++
  4306.  
  4307. >From rmah@panix.com (Robert Mah)
  4308. Date: Sat, 20 Aug 1994 09:54:50 -0500
  4309. Organization: One Step Beyond
  4310.  
  4311. dnebing@andy.bgsu.edu (bgsuvax) wrote:
  4312.  
  4313. ) Standards are good if they are robust and evolve with change.  However
  4314. ) the HIG standard, while at first introduction was quite robust, didn't
  4315. ) keep up with what was being published in the industry.
  4316.  
  4317. This is an irrelavent argument.  There is no "human interface" industry
  4318. to keep up with (though I understand you meant the computer or software
  4319. industry).  And I would argue that keeping up with the Joneses is not
  4320. a worthy goal.
  4321.  
  4322. Human interface design should pay more attention to new perspectives in
  4323. the fields of psycology, sociology, cognition, perception, linguistics,
  4324. learning theory, etc. than the computer and software field.  These "soft"
  4325. fields are much more important, because the purpose of human interface
  4326. design is to mold the machine (or software) the person.  A better under-
  4327. standing of human behaviour will lead to better designs.
  4328.  
  4329.  
  4330. ) Take for example Word's toolbar that can be found in most of their apps
  4331. ) now and can also be found in other vendor's apps (i.e. CodeWarrior).
  4332. ) The HIGs never evolved to encompass toolbars, hence the thread that
  4333. ) started here some time back about toolbar icons representing nouns or
  4334. ) verbs, and which was appropriate.
  4335.  
  4336. The previous discussion to which you refer was more about whether one 
  4337. should mix nouns, verbs and adjectives/adverbs in palettes.
  4338.  
  4339. Microsoft made the cardinal sin of not considering the underlying rational
  4340. for tool palettes (e.g. in paint programs).  They never stopped to examine
  4341. just what was being presented to the user and why tool palettes were a
  4342. valuable addition to the user interface.
  4343.  
  4344. Instead, they said (or so I surmise)...
  4345.  
  4346.   "Let's add icons -- icons are cool."
  4347.   "But what icons?  We don't have any tools like paint bucket in Word..."
  4348.   "How about something for the basic commands like print and save?"
  4349.   "Yeah, that's it!"
  4350.   "OK, how 'bout a spell checker icon?"
  4351.   "Cool man."
  4352.   ...
  4353.   ...
  4354.   "Uh, Joe, what does that icon mean?"
  4355.   "Oh, that's the 'Paste special' icon, can't you tell?"
  4356.   "Well, no...I guess we should add some help"
  4357.   "Great idea!  That way, no one will get confused because we'll have
  4358.    text explaining what each icon does!"
  4359.   "Cool man."
  4360.  
  4361. My question: if you need text to explain a large percentage of the icons,
  4362. then why use the silly icons in the first place?
  4363.  
  4364. The REASON why the toolbars in word and excel (and other programs) are 
  4365. undeciferable by modern man are twofold.
  4366.  
  4367. 1. They depart from the normal practice of using icons to represent nouns.
  4368.    That is _things_ that can be manipulated.
  4369.  
  4370. 2. Each application has it's own "vocabulary", leading to a Tower of Babel.
  4371.    Users must learn a new and different "iconic language" for each app.
  4372.    This is obviouslly not a good thing.
  4373.  
  4374. If there were a standardized vocabulary AND verb-icons could be visually
  4375. distinguished from noun-icons and modifier-icons (i.e. adjectives and 
  4376. adverbs) then, and only then, will toolbars become a truely useful interface
  4377. element.
  4378.  
  4379. Note that, on the Mac anyway, there is already a standardized vocuabulary
  4380. for many graphics app-oriented tool icons.  Color seed fill tools are paint 
  4381. buckets.  Color grabbers are little eye droppers.  Pencils draw points and
  4382. free form lines that follow the cursor.  This standardized vocabulary 
  4383. allows these tools to become "invisble" once they learn them.  Learn them
  4384. once.
  4385.  
  4386. This goes back to more subtle things like the Apple's own special look for
  4387. floating windows.  Now people have to recognize TWO types of windows as 
  4388. floaters.  This is not good.
  4389.  
  4390. Phew!  Enough typing for now.
  4391.  
  4392. Cheers,
  4393. Rob
  4394. _____________________________________________________________________
  4395. Robert S. Mah           Software Development          +1.212.947.6507
  4396. One Step Beyond        and Network Consulting          rmah@panix.com
  4397.  
  4398. +++++++++++++++++++++++++++
  4399.  
  4400. >From dnebing@andy.bgsu.edu (bgsuvax)
  4401. Date: 20 Aug 1994 18:15:31 GMT
  4402. Organization: Bowling Green State University
  4403.  
  4404.   Whew, mention Word's toolbars and I end up catching some flames! ;-)
  4405.  
  4406.   Anyway, all points mentioned about Word's toolbars don't have much
  4407. thought behind them are true.  I never meant to say that Word's interface
  4408. was the best and we should all turn towards Washington and say "We're
  4409. not worthy!"
  4410.  
  4411.   I did want to show how graphical elements like Word's toolbar have
  4412. been popping up and there is nothing in the HIGs to govern their appearance
  4413. nor what they should contain (nouns, verbs, adjectives/adverbs).  Other
  4414. items have been world floating windows, system menus, etc.  There are
  4415. lots of examples of things that have been done which aren't covered in
  4416. the HIGs.  Do the HIGs say anything about removing the Help menu like
  4417. SpeedyFinder does, etc.
  4418.  
  4419.   As far as Word's toolbar goes, I like it.  I like the fact that I
  4420. can set up my own tool to represent a command which I might use from
  4421. time to time that I forget what the key combination is (is that cmd-opt-u
  4422. or cmd-opt-cntrl-u or cmd-opt-shift-u ...).
  4423.  
  4424.   Other apps have been adding toolbars, too.  OmniPage 5.0 has one,
  4425. most MS products have one, I understand that CodeWarrior has one too.
  4426. Toolbars are showing up all over the place, but the HIGs don't say
  4427. whether nouns, verbs, or adj/advs should be used.
  4428.  
  4429.   My whole point was that the HIGs have to be constantly evolving to
  4430. cover new things like toolbars, etc.  You can't just set up some standards
  4431. and expect them to stay golden forever without change.
  4432.  
  4433.   Dave
  4434.  
  4435. ============================================================
  4436. Dave Nebinger                    dnebing@bgsuvax.bgsu.edu
  4437. Network Manager, Biology Dept.   dnebing@opie.bgsu.edu
  4438. Bowling Green State University   dnebing@bgsuopie (bitnet)
  4439. Bowling Green, OH 43403          #include <std_disclaimer.h>
  4440.  
  4441.              *THE* alt.sources.mac supporter!
  4442.  
  4443. +++++++++++++++++++++++++++
  4444.  
  4445. >From Jaeger@fquest.com (Brian Stern)
  4446. Date: 20 Aug 1994 18:21:56 GMT
  4447. Organization: The University of Texas at Austin, Austin, Texas
  4448.  
  4449. In article <rmah-2008940954500001@rmah.dialup.access.net>, rmah@panix.com
  4450. (Robert Mah) wrote:
  4451.  
  4452. > The REASON why the toolbars in word and excel (and other programs) are 
  4453. > undeciferable by modern man are twofold.
  4454. > 1. They depart from the normal practice of using icons to represent nouns.
  4455. >    That is _things_ that can be manipulated.
  4456. > 2. Each application has it's own "vocabulary", leading to a Tower of Babel.
  4457. >    Users must learn a new and different "iconic language" for each app.
  4458. >    This is obviouslly not a good thing.
  4459. > If there were a standardized vocabulary AND verb-icons could be visually
  4460. > distinguished from noun-icons and modifier-icons (i.e. adjectives and 
  4461. > adverbs) then, and only then, will toolbars become a truely useful interface
  4462. > element.
  4463. > Note that, on the Mac anyway, there is already a standardized vocuabulary
  4464. > for many graphics app-oriented tool icons.  Color seed fill tools are paint 
  4465. > buckets.  Color grabbers are little eye droppers.  Pencils draw points and
  4466. > free form lines that follow the cursor.  This standardized vocabulary 
  4467. > allows these tools to become "invisble" once they learn them.  Learn them
  4468. > once.
  4469. > Phew!  Enough typing for now.
  4470. > Cheers,
  4471. > Rob
  4472. > _____________________________________________________________________
  4473. > Robert S. Mah           Software Development          +1.212.947.6507
  4474. > One Step Beyond        and Network Consulting          rmah@panix.com
  4475.  
  4476.  
  4477. Let me add a bit of grist to this mill.  It is simply not true that icons
  4478. on the Mac are always used as nouns.  This is true in the Finder where
  4479. icons represent files, and in Resedit.  The icon buttons used in graphics
  4480. programs indicate something like 'change the cursor to a pencil tool' or
  4481. 'change the cursor to the paint bucket tool'.  Icon buttons are a hybrid
  4482. between icons and buttons.  All buttons act as verbs, including icon
  4483. buttons.  I don't think there is ever a confusion between icons-as-nouns
  4484. and icons-as-verbs.  The drop shadow
  4485.  
  4486. One could argue that the calculater DA uses a primitive icon-button
  4487. interface.  The '*' and '/' and '+' keys use symbols to indicate their
  4488. functions.  These buttons are also not standard Mac pushbuttons.  This
  4489. interface works because it's so similar to real calculaters that there is
  4490. little or no learning curve.
  4491.  
  4492. Hypercard uses '->' buttons to indicate 'go to the next card'.
  4493.  
  4494. The old Font/DA mover had a standard pushbutton with '>>' on it to
  4495. transfer fonts from the left list box to the right list box.  Admittedly
  4496. that interface wasn't God's gift to interfaces but it is a case where a
  4497. symbol, rather than words was used on a button.  That interface lives on
  4498. in lots of places, like 'Add Files' dialog boxes, although often there is
  4499. a word rather than a symbol.  Presumably we'll be seeing drag-and-drop
  4500. replacements for this RSN ;).
  4501.  
  4502. The problem with icon buttons is that it's often hard to remember what
  4503. they represent and there are often too damn many of them.  FWIW I never
  4504. use Word's toolbar.  (Also Word's toolbar takes a loooong time to
  4505. redraw.)  In Word's defense the toolbar can be turned off, and anything
  4506. that you can do with the toolbar can also be done with the menus, and in
  4507. many cases with command key equivalents.
  4508.  
  4509. The icons on icon buttons are simply meant to replace the words that would
  4510. go there.  And this is done to save space on the buttons, and to be cool,
  4511. of course.  I think that the key to good icon buttons is to have not very
  4512. many of them.  That allows you to remember what they do.
  4513.  
  4514. -- 
  4515. Brian  Stern  :-{)}
  4516. Jaeger@fquest.com
  4517.  
  4518. +++++++++++++++++++++++++++
  4519.  
  4520. >From rmah@panix.com (Robert Mah)
  4521. Date: Sat, 20 Aug 1994 20:42:57 -0500
  4522. Organization: One Step Beyond
  4523.  
  4524. Jaeger@fquest.com (Brian Stern) wrote:
  4525.  
  4526. ) Let me add a bit of grist to this mill.  It is simply not true that icons
  4527. ) on the Mac are always used as nouns.  This is true in the Finder where
  4528. ) icons represent files, and in Resedit.  The icon buttons used in graphics
  4529. ) programs indicate something like 'change the cursor to a pencil tool' or
  4530. ) 'change the cursor to the paint bucket tool'.  Icon buttons are a hybrid
  4531. ) between icons and buttons.  All buttons act as verbs, including icon
  4532. ) buttons.  I don't think there is ever a confusion between icons-as-nouns
  4533. ) and icons-as-verbs.  The drop shadow
  4534.  
  4535. To you, the programmer, the pencil icon may mean, "change internal mode to
  4536. kPencilToolMode", but to the user it means, "I wanna use the pencil now".
  4537. That is, the icon is a graphical representation of a tool, a thing.  That
  4538. this "thing" doesn't actually exist is not relavent.  I.e. when I talk 
  4539. about nouns-vs-verbs, I'm looking at the icons from the user's viewpoint.
  4540.  
  4541. Icon buttons, without text are, IMO, not good, because they try to represent
  4542. actions as icons.  Same problem as MS-style toolbars.
  4543.  
  4544.  
  4545.  
  4546. ) One could argue that the calculater DA uses a primitive icon-button
  4547. ) interface.  The '*' and '/' and '+' keys use symbols to indicate their
  4548. ) functions.  These buttons are also not standard Mac pushbuttons.  This
  4549. ) interface works because it's so similar to real calculaters that there
  4550. ) is little or no learning curve.
  4551.  
  4552. Software calculator interfaces work because of three reasons...
  4553.  
  4554. 1. As you mention, there are real world analogues to the user interface.
  4555.  
  4556. 2. The buttons represent well known concepts (the digits, adding etc.)
  4557.  
  4558. 3. The graphical representation of these concepts have been standardized.
  4559.    I.e. there is a common and accepted vocabulary.  "+" means add.  "="
  4560.    means equals.  Etc.
  4561.  
  4562. Thus, as you say, there is no confusion.  However, imagine what would
  4563. happen if you added a "save paper tape to file" button to the caculator
  4564.  
  4565. Note that, in this specific case, the criteria that I set forth for the
  4566. use of icons to represent verbs have been fullfiled.  Thus, it works. 
  4567. Most applications and software in general do not fullfil these criteria.
  4568.  
  4569.  
  4570. ) Hypercard uses '->' buttons to indicate 'go to the next card'.
  4571.  
  4572. Don't even get me started on HyperCard!  No thought seemed to have been
  4573. given to interface design on that thing.  Problems like floating palettes
  4574. that de-hilite, fixed window sizes, dynamically changing menus, too many
  4575. modes, modal editors, etc.  Many problems were fixed in later versions
  4576. and the current one is actually starting to get decent.
  4577.  
  4578.  
  4579. ) The old Font/DA mover had a standard pushbutton with '>>' on it to
  4580. ) transfer fonts from the left list box to the right list box.  Admittedly
  4581. ) that interface wasn't God's gift to interfaces but it is a case where a
  4582. ) symbol, rather than words was used on a button.  That interface lives on
  4583. ) in lots of places, like 'Add Files' dialog boxes, although often there is
  4584. ) a word rather than a symbol.  Presumably we'll be seeing drag-and-drop
  4585. ) replacements for this RSN ;).
  4586.  
  4587. Ever remember seeing someone try to figure out Font/DA Mover?  The concept
  4588. is simple to those who understand the mechanics, but to normal users who
  4589. don't want to understand resources and such, it was a royal nightmare.
  4590.  
  4591. Wouldn't it have been better to title the buttons as "Move ->" or even
  4592. better "Move To File XYZ".  Or even better, drop the damn thing and move
  4593. its functionality to the Finder where people don't have to learn yet
  4594. another method of moving objects around.
  4595.  
  4596. Cheers,
  4597. Rob
  4598. _____________________________________________________________________
  4599. Robert S. Mah           Software Development          +1.212.947.6507
  4600. One Step Beyond        and Network Consulting          rmah@panix.com
  4601.  
  4602. +++++++++++++++++++++++++++
  4603.  
  4604. >From hanrek@cts.com (Mark Hanrek)
  4605. Date: 21 Aug 1994 01:37:23 GMT
  4606. Organization: The Information Workshop
  4607.  
  4608.  
  4609. When I explain what is heappening in the world of computers to
  4610. non-computer people, I like to draw an analogy to the early days of
  4611. automobiles, when between the different manufacturers, there were
  4612. different ways to steer, and different ways to start, stop, and make the
  4613. horseless-carriage go.
  4614.  
  4615. Maybe that analogy is useful in this discussion.
  4616.  
  4617. Today, we can get into a 1965 Galaxie 500, or a 1994 Supra, and easily
  4618. know what to do to drive either of them.
  4619.  
  4620. Perhaps we are at the stage where we can be a little loose, and allow for
  4621. some differing styles on our screens.
  4622.  
  4623. As long as the close box, zoom box, grow box, and drag bar are clearly
  4624. obvious and work the expected ways, a window is a window.
  4625.  
  4626. The same with buttons.
  4627.  
  4628. Maybe this is the beginning of wriggling out of the super-restricted
  4629. user-interface thinking we have been in for so long.
  4630.  
  4631. At first it was "the march to enforce consistency", and the Macintosh made
  4632. its point.  Now that we have done that, and everyone understands the
  4633. fundamental value of consistency, we can let up and allow some style.
  4634.  
  4635. You know those telephones with the gigantic numbers on buttons that are 2
  4636. inches on a side?....
  4637.  
  4638. :)
  4639.  
  4640. Mark Hanrek
  4641. The Information Workshop
  4642.  
  4643. +++++++++++++++++++++++++++
  4644.  
  4645. >From nagle@netcom.com (John Nagle)
  4646. Date: Sun, 21 Aug 1994 02:21:21 GMT
  4647. Organization: NETCOM On-line Communication Services (408 261-4700 guest)
  4648.  
  4649. sanford@CS.Arizona.EDU (Sanford H. Selznick) writes:
  4650. >Of course the graphic calculator that comes with the PPC blows
  4651. >everything else away... and that's a step in the right direction.  Not
  4652. >funky post-its.  
  4653.  
  4654.       Agreed.  With the PowerMac, application developers are guaranteed
  4655. a certain floor of performance, which makes possible apps that depend
  4656. on that floor.  Graphic Calculator is an example; something like that
  4657. is too unwieldy to use if it updates slowly.  3D editing programs can
  4658. be written to assume the model can be manipulated interactively.  
  4659. Look at Ashlar Vellum for something that intelligently uses CPU
  4660. time in an interactive way.
  4661.  
  4662.       This is the way to a "killer app" that sells PowerMacs to PC
  4663. users.  Unless Apple comes up with something that moves users from
  4664. PCs to Macs, Apple's market share will steadily decrease, because users
  4665. are already moving the other way.
  4666.  
  4667.                     John Nagle
  4668.  
  4669. +++++++++++++++++++++++++++
  4670.  
  4671. >From ari@world.std.com (Ari I Halberstadt)
  4672. Date: Sun, 21 Aug 1994 02:49:17 GMT
  4673. Organization: The World Public Access UNIX, Brookline, MA
  4674.  
  4675. In article <1994Aug19.031720.1465@kira.net.netcom.com>,
  4676. David John Burrowes <netcom.com!kira!davidjohn> wrote:
  4677. >If you've read this far, I'm curious what your thoughts are, either through  
  4678. >personal email or on the newsgroup.  Maybe I'm very much in the minority,  
  4679. >and folks generally think the 'highly consistent' interface was too  
  4680. >constraining?
  4681.  
  4682. Others must have noticed that Apple, Microsoft, and any plethora of
  4683. other GUI builders are doing what they've always been doing. Stealing
  4684. (uh, adapting) ideas from eachother. Apple anounces a new feature,
  4685. Microsoft isn't far behind. Microsoft announces a new feature, Apple
  4686. isn't far behind (my favorite example of this is preemptive
  4687. multitasking and threads). What you're seeing is Apple doing what it
  4688. has always done, and will continue to do. Their documentation as to
  4689. "standards" is temporary gibberish; there are so many standards of
  4690. such short life-spans, that the term "standard" in computer-world has
  4691. little meaning. In the end, I don't think users really care if their
  4692. buttons are 3-D shadowed, or if they're rounded, square, or whatever.
  4693. They just want software that's useful or fun, or that, at a minimum,
  4694. marketing can convince them to buy. It doesn't really matter if it's a
  4695. mac, a windows, a car, a dog, or a cat. People are people are people,
  4696. and will always behave as people. Oh gosh, I'm straying. Let me get
  4697. off of my soap box.
  4698.  
  4699. Ah, that's better. Cheers!
  4700. -- 
  4701. Ari Halberstadt                                 ari@world.std.com
  4702. One generation passes away, and another generation comes: but the
  4703. earth abides for ever. -- Ecclesiastes, 1:4.
  4704.  
  4705. +++++++++++++++++++++++++++
  4706.  
  4707. >From ari@world.std.com (Ari I Halberstadt)
  4708. Date: Sun, 21 Aug 1994 03:10:46 GMT
  4709. Organization: The World Public Access UNIX, Brookline, MA
  4710.  
  4711. In article <gurgle-1908941023500001@gurgle.dnai.com>,
  4712. Pete Gontier <gurgle@dnai.com> wrote:
  4713. >Frankly, from what I've seen of System 7.5, there's less and less reason
  4714. >to develop for Macintosh. That ought to scare the shit out of Apple,
  4715. >because the only way they'll survive is if people think there's reason to
  4716. >bother.
  4717.  
  4718. For me, it's not 7.5. It's the pathetic state of the APIs and
  4719. documentation. Who wants to spend their life looking through 16000
  4720. pages? There is no reason the OS needs to be that complicated. And no,
  4721. a legacy OS is not a reason for rampant complexity. And OpenDoc is
  4722. only going to make it worse. Oh ya, and six (SIX!!!) books for QDGX.
  4723. Geesh. Unfortunately for the world, Microsoft is making the exact same
  4724. mistakes. Oh well.
  4725.  
  4726. And then, there are the development tools. We all know what sorry
  4727. state they've been in and continue to be in. And the pathetic
  4728. languages used for development (this isn't a mac-only problem; none of
  4729. this is a mac-only problem).
  4730.  
  4731. Finally, there's the market share. Many more windows machines than
  4732. macs. Solution? Some cross-platform package. Well, then you get into
  4733. deciding which one to use, will the company be around, convincing your
  4734. engineers, etc.
  4735.  
  4736. Why do I do mac development? Because I learned it years ago and manage
  4737. to keep up with a minimum of the dumb system junk they produce. And I
  4738. can still get work doing it, because there are several million macs
  4739. out there, and that's a reasonably sized market. And because learning
  4740. another OS is a major hastle (see above). And it pays my bills so I
  4741. can do what I want to do. And no, that's not program computers all the
  4742. time. Really. No, really.
  4743.  
  4744. Here's my schpiel: computers suck. They all suck. But they're useful
  4745. tools for certain problems. But give me 50 years, maybe 100, and no
  4746. one will talk of digital computers. It will be about systems that
  4747. immitate biological systems. We all run around with the most powerful
  4748. information processing system on our shoulders. It's the ultimate in
  4749. portability. Well, obviously we don't do matrix multiplications too
  4750. fast, but that's about all computers beat us at. Yes, biology is the
  4751. future. Even a single living cell (even a bacterium!) puts computers
  4752. to shame. Small, efficient, fast, robust (!!), disposable, recyclable.
  4753. Engineering on the atomic level. People who talk about nano-machines
  4754. don't know squat about the future. An enzyme is a nano-machine, built
  4755. atom by atom, in a process no one can describe fully. And you've got
  4756. so many trillions of them, constantly being built and destroyed, of
  4757. such an incredible variety. Really, computers do suck. And yes,
  4758. they're useful tools. Heck, they pay the food bills, so this
  4759. biological entity can continue to pontificate and study itself :-)
  4760.  
  4761. -- 
  4762. Ari Halberstadt                                 ari@world.std.com
  4763. One generation passes away, and another generation comes: but the
  4764. earth abides for ever. -- Ecclesiastes, 1:4.
  4765.  
  4766. +++++++++++++++++++++++++++
  4767.  
  4768. >From ari@world.std.com (Ari I Halberstadt)
  4769. Date: Sun, 21 Aug 1994 03:19:49 GMT
  4770. Organization: The World Public Access UNIX, Brookline, MA
  4771.  
  4772. In article <gurgle-1908941028350001@gurgle.dnai.com>,
  4773. Pete Gontier <gurgle@dnai.com> wrote:
  4774. >I don't think "refused" is quite the right word. I think what's going on
  4775. >is that Apple is a disgusting fragmented byzantine re-organized
  4776. >bureaucracy at this point. Nobody has the authority to put their foot down
  4777. >and say "dammit, add floating window support to the Window Manager". Lots
  4778. >of people can produce paperwork showing why it should wait until next year
  4779. >when the Frobozzination Manager comes out. But nobody can put their foot
  4780. >down.
  4781.  
  4782. I put my foot down. Oh, but it doesn't seem to have done any good :-)
  4783.  
  4784. Too bad the only PC company to come along in the last 10 years to
  4785. offer something useful died (well, sort of, it's not dead yet). NeXT
  4786. of course. We could all have been 5 years ahead of the game had NeXT
  4787. pinned Apple and MS against the ropes.
  4788. -- 
  4789. Ari Halberstadt                                 ari@world.std.com
  4790. One generation passes away, and another generation comes: but the
  4791. earth abides for ever. -- Ecclesiastes, 1:4.
  4792.  
  4793. +++++++++++++++++++++++++++
  4794.  
  4795. >From ari@world.std.com (Ari I Halberstadt)
  4796. Date: Sun, 21 Aug 1994 03:26:00 GMT
  4797. Organization: The World Public Access UNIX, Brookline, MA
  4798.  
  4799. In article <9668AA7AE24F.450EE@klkmac004.nada.kth.se>,
  4800. Jon W{tte <h+@nada.kth.se> wrote:
  4801. >However, I have this feeling people are not going to use this 
  4802. >floating WDEF, since the title bar is too bloody large for most 
  4803. >floating pallette uses - Apple says that's to make it easier to 
  4804. >hit for newbies, but to me, that seems less important than real 
  4805. >productivity for real users...
  4806.  
  4807. Why couldn't they just have bought Troy's cool Windoid (or done their
  4808. own, if they disliked the idea of anyone ever knowing that Apple ever
  4809. had anything to do with something that was, gasp, free with source
  4810. code) and added a "Windows" control panel that let users set the
  4811. height of stupid title bar? Users who need BIG title bars could click
  4812. the BIG TITLE BAR button, and users who need tiny title bars could
  4813. click the tiny title bar button, and super expert users could enter a
  4814. measurement (in centimeters or inches, NOT pixels) into a little text
  4815. field. The modifications to the windoid to make its title bar's height
  4816. adjustable would have been miniscule, and would have made the UI
  4817. adaptable to the particular needs of individuals with minimal impact
  4818. on overall consistency.
  4819. -- 
  4820. Ari Halberstadt                                 ari@world.std.com
  4821. One generation passes away, and another generation comes: but the
  4822. earth abides for ever. -- Ecclesiastes, 1:4.
  4823.  
  4824. +++++++++++++++++++++++++++
  4825.  
  4826. >From ari@world.std.com (Ari I Halberstadt)
  4827. Date: Sun, 21 Aug 1994 03:30:46 GMT
  4828. Organization: The World Public Access UNIX, Brookline, MA
  4829.  
  4830. In article <1994Aug19.215703@west.cscwc.pima.edu>,
  4831.  <103t_english@west.cscwc.pima.edu> wrote:
  4832. >I think that it is obvious that 7.5 is a rush-job. Aside from AppleScript,
  4833. >AOCE, GX nad one or two other exceptions, the new stuff in 7.5 all appears to
  4834. >be licensed from 3rd parties and included as is without any attempt to make it
  4835. >more System 7-ish.
  4836.  
  4837. With all those 3-rd party ideas included in sys 7.5, why, oh why,
  4838. couldn't they have included drop-down menus and stick-up menus? It
  4839. would have made life so much easier on my tired hands (that have to
  4840. click, hold, and drag to access a menu command, a very very bad thing
  4841. from a human engineering POV).
  4842. -- 
  4843. Ari Halberstadt                                 ari@world.std.com
  4844. One generation passes away, and another generation comes: but the
  4845. earth abides for ever. -- Ecclesiastes, 1:4.
  4846.  
  4847. +++++++++++++++++++++++++++
  4848.  
  4849. >From sanford@CS.Arizona.EDU (Sanford H. Selznick)
  4850. Date: 20 Aug 1994 20:21:36 -0700
  4851. Organization: University of Arizona CS Department, Tucson AZ
  4852.  
  4853. In article <Cuv6I6.MyG@world.std.com>,
  4854. [poof!]
  4855. >... In the end, I don't think users really care if their
  4856. >buttons are 3-D shadowed, or if they're rounded, square, or whatever.
  4857. >They just want software that's useful or fun, or that, at a minimum,
  4858. >marketing can convince them to buy. It doesn't really matter if it's a
  4859. >mac, a windows, a car, a dog, or a cat.
  4860.  
  4861. So this actually brings up an important point.  Is the mac supposed to
  4862. be a computer to _buy_ or a computer to _use_?  Is there a happy
  4863. medium?
  4864.  
  4865. I say yes, but not when you put mail software under the special menu
  4866. and Shut Down in the Apple menu.  What percentage of macs end up on a 
  4867. network anyway?  (Does it even do POP3?)  The transition from 6 to 7
  4868. added a lot of good features.  The transition from 7 to 7.5 adds too
  4869. many bells and whistles for my taste.
  4870.  
  4871. As I bring up yet one more point in the same breath...
  4872.  
  4873. When I'm not in school or working for the U, I do independent
  4874. consulting.  One thing I can always count on is macintosh consistency.
  4875. I can sit down at any mac and know my way around.  The users (once
  4876. they get good, and they do so rather quickly) see this too.  And that
  4877. too is a selling feature they they can talk about to their friends.
  4878. Different is good.  Different with efficiency is even better.
  4879.  
  4880. IMHO,
  4881.   Sanford
  4882.  
  4883.  
  4884. +++++++++++++++++++++++++++
  4885.  
  4886. >From ari@world.std.com (Ari I Halberstadt)
  4887. Date: Sun, 21 Aug 1994 03:43:35 GMT
  4888. Organization: The World Public Access UNIX, Brookline, MA
  4889.  
  4890. In article <rmah-2008940954500001@rmah.dialup.access.net>,
  4891. Robert Mah <rmah@panix.com> wrote:
  4892. >Human interface design should pay more attention to new perspectives in
  4893. >the fields of psycology, sociology, cognition, perception, linguistics,
  4894. >learning theory, etc. than the computer and software field.  These "soft"
  4895. >fields are much more important, because the purpose of human interface
  4896. >design is to mold the machine (or software) the person.  A better under-
  4897. >standing of human behaviour will lead to better designs.
  4898.  
  4899. Ok, here's the new alert for deleting a locked file:
  4900.  
  4901. "While it's ok to delete a locked file, you should remember that this
  4902. does not deal with the more basic problem of why the file is locked.
  4903. Merely deleting this file will not solve your problems, which arrise
  4904. out of years of neglect and rejection.
  4905.  
  4906.        -----------------  --------------------   ----------------
  4907.       | Call My Shrink | | Load Caring Mother | | Please Help Me |
  4908.        ----------------   --------------------  | Understand My  |
  4909.                                                 | Inner Child    |
  4910.                                                  ----------------
  4911. "
  4912.  
  4913. Sorry, I couldn't resist it. I do agree with Rob, though.
  4914.  
  4915. Boy, this thread is so much fun. I haven't posted so many stupid and
  4916. irrelevant things since, uh, oh I don't know.
  4917. -- 
  4918. Ari Halberstadt                                 ari@world.std.com
  4919. One generation passes away, and another generation comes: but the
  4920. earth abides for ever. -- Ecclesiastes, 1:4.
  4921.  
  4922. +++++++++++++++++++++++++++
  4923.  
  4924. >From rmah@panix.com (Robert Mah)
  4925. Date: Sun, 21 Aug 1994 05:55:39 -0500
  4926. Organization: One Step Beyond
  4927.  
  4928. ari@world.std.com (Ari I Halberstadt) wrote:
  4929.  
  4930. ) Ok, here's the new alert for deleting a locked file:
  4931. ) "While it's ok to delete a locked file, you should remember that this
  4932. ) does not deal with the more basic problem of why the file is locked.
  4933. ) Merely deleting this file will not solve your problems, which arrise
  4934. ) out of years of neglect and rejection.
  4935. )        -----------------  --------------------   ----------------
  4936. )       | Call My Shrink | | Load Caring Mother | | Please Help Me |
  4937. )        ----------------   --------------------  | Understand My  |
  4938. )                                                 | Inner Child    |
  4939. )                                                  ----------------
  4940.  
  4941. Damn that's funny!  I'm not quite sure _why_ I thought it was so funny..
  4942. ..maybe it has something to do with supressed memories of my childhood..
  4943.  
  4944. Cheers,
  4945. Rob
  4946. _____________________________________________________________________
  4947. Robert S. Mah           Software Development          +1.212.947.6507
  4948. One Step Beyond        and Network Consulting          rmah@panix.com
  4949.  
  4950. +++++++++++++++++++++++++++
  4951.  
  4952. >From Jaeger@fquest.com (Brian Stern)
  4953. Date: 21 Aug 1994 12:48:46 GMT
  4954. Organization: The University of Texas at Austin, Austin, Texas
  4955.  
  4956. In article <rmah-2008942042570001@rmah.dialup.access.net>, rmah@panix.com
  4957. (Robert Mah) wrote:
  4958.  
  4959. > Jaeger@fquest.com (Brian Stern) wrote:
  4960. > ) Let me add a bit of grist to this mill.  It is simply not true that icons
  4961. > ) on the Mac are always used as nouns.  This is true in the Finder where
  4962. > ) icons represent files, and in Resedit.  The icon buttons used in graphics
  4963. > ) programs indicate something like 'change the cursor to a pencil tool' or
  4964. > ) 'change the cursor to the paint bucket tool'.  Icon buttons are a hybrid
  4965. > ) between icons and buttons.  All buttons act as verbs, including icon
  4966. > ) buttons.  I don't think there is ever a confusion between icons-as-nouns
  4967. > ) and icons-as-verbs.  The drop shadow
  4968. > To you, the programmer, the pencil icon may mean, "change internal mode to
  4969. > kPencilToolMode", but to the user it means, "I wanna use the pencil now".
  4970. > That is, the icon is a graphical representation of a tool, a thing.  That
  4971. > this "thing" doesn't actually exist is not relavent.  I.e. when I talk 
  4972. > about nouns-vs-verbs, I'm looking at the icons from the user's viewpoint.
  4973. > Icon buttons, without text are, IMO, not good, because they try to represent
  4974. > actions as icons.  Same problem as MS-style toolbars.
  4975. > Cheers,
  4976. > Rob
  4977. > _____________________________________________________________________
  4978. > Robert S. Mah           Software Development          +1.212.947.6507
  4979. > One Step Beyond        and Network Consulting          rmah@panix.com
  4980.  
  4981. All buttons represent verbs; if you click a button then some action
  4982. occurs.  Buttons also have some information on them to help you remember
  4983. the action associated with them.  In the traditional case this is in the
  4984. form of words, in the case at hand it is little pictures.  I agree that we
  4985. should look at this from the user's perspective.  
  4986.  
  4987. Clicking on the pencil button does mean 'use the pencil now', and that's
  4988. an action, not a noun.  If a graphics program was to maintain the Finder's
  4989. paradigm of 'select a file and then select an action to be done to that
  4990. file', there would be a tool palette that had some number of tool icons on
  4991. it.  To change the current tool to the pencil the user would select the
  4992. pencil icon in the tool palette and then choose a menu item or hit a
  4993. standard button that said something like 'use selected tool'.  This could
  4994. work but would probably be less convenient than the icon-button approach.
  4995.  
  4996. The fact that these buttons have icons on them is an implementation
  4997. detail.  I think that you're seeing them from a programmer's perspective. 
  4998. I doubt that many users think of these as icon-buttons.  They're merely
  4999. buttons.  I don't believe that there is any confusion between the pictures
  5000. on these buttons and the pictures that the Finder shows you.  Everyone
  5001. knows that clicking on a button does something.  The hard part is
  5002. remembering or figuring out what a particular button does.
  5003.  
  5004. I agree that excessive use of icon-buttons causes problems (see your
  5005. physician or clergyman for treatment:)  I don't agree that this has
  5006. anything to do with nouns or verbs.  The problem is that when you have a
  5007. whole slew of them it's very hard to remember what they all do.
  5008.  
  5009. One of the most important strengths of the Mac interface is the way that
  5010. it's easy to remember how things work.  When people say that the Mac
  5011. interface is intuitive what they really mean is that things are 'easy to
  5012. remember'.  Intuitive really means 'easy to figure out'.  Icon buttons are
  5013. usually not 'easy to remember' and they're often not 'easy to figure out'
  5014. either.
  5015.  
  5016. -- 
  5017. Brian  Stern  :-{)}
  5018. Jaeger@fquest.com
  5019.  
  5020. +++++++++++++++++++++++++++
  5021.  
  5022. >From rmah@panix.com (Robert Mah)
  5023. Date: Sun, 21 Aug 1994 14:47:56 -0500
  5024. Organization: One Step Beyond
  5025.  
  5026. Jaeger@fquest.com (Brian Stern) wrote:
  5027. ) All buttons represent verbs; if you click a button then some action occurs.
  5028.  
  5029. Yes, I'll agree with this.  However, tool palettes as commonly used in
  5030. graphics apps are not like normal buttons because they stay hilited
  5031. over time.  Normal buttons initiate an action and then return to their
  5032. unhilited state immediately (or should).  
  5033.  
  5034. But leaving that asside for now, you raise an interesting point...
  5035.  
  5036.  
  5037. ) Clicking on the pencil button does mean 'use the pencil now', and
  5038. ) that's an action, not a noun. 
  5039.  
  5040. If you point to the pencil tool icon and ask users, "what is that?" 
  5041. Most usrers will not say, "that's the button that turns on the pencil
  5042. tool".  They will say, "that's the pencil tool".  That icon has taken on
  5043. the meaning of that tool.  It is a word, expressed as a heiroglyph that
  5044. represents the tool, "pencil", in the mind of the user.  In short, a noun.
  5045.  
  5046. Turning that around, if you ask, "what does that do?", then they may say,
  5047. "it lets me use the pencil".
  5048.  
  5049. The reason for this seeming dichotomy is the question itself.  The second
  5050. question was phrased in a manner that elicits a functional responce
  5051. instead of a descriptive one. 
  5052.  
  5053. This can be easily turned around and used to "proove" that a common soft-
  5054. ware "verb" is actually a "noun".  Point to the a scroll bar in a window
  5055. and ask, "What is that?".  Which could easily lead to a responce such as,
  5056. "That's a scroll bar".  Then again, ask, "What does this do?" and you, of
  5057. course, get, "It makes the text move up and down".
  5058.  
  5059. It's all a matter of perspective and language.
  5060.  
  5061.  
  5062. ) I agree that excessive use of icon-buttons causes problems (see your
  5063. ) physician or clergyman for treatment:)  I don't agree that this has
  5064. ) anything to do with nouns or verbs.  The problem is that when you have
  5065. ) a whole slew of them it's very hard to remember what they all do.
  5066. ) [...]
  5067. ) Icon buttons are usually not 'easy to remember' and they're often not 
  5068. ) 'easy to figure out' either.
  5069.  
  5070. One point in differentiating between "noun" icons and "verb" icons is that
  5071. a standard vocabulary is much easier to build with "noun" icons.  That is
  5072. why, in fact, a small one already has.  It's easier because "nouns" are
  5073. often used to represent software-things which one can easily represent
  5074. with a picture of a similar real-world analogue.
  5075.  
  5076. Verbs, however, by their very nature are more ephemeral.  They are not as
  5077. easily represented by pictures, and in fact, some designers have taken to
  5078. using pictures of _things_ to represent _actions_.  E.g. printer icon
  5079. buttons to print documents.  This is NOT the same as the use of printer
  5080. icons in Quickdraw GX on the desktop.  Here, they are used to represent
  5081. things...a destination that prints documents.  So, it fits within the
  5082. overall scheme of the Finder.
  5083.  
  5084.  
  5085. So, finally, I would like to stress that it's not toolbars, per se, that
  5086. bother me, it's the gratuitous use of babbeling icons to represent actions
  5087. (i.e. verbs) without regard for standardization.
  5088.  
  5089. The icons used in these buttons ARE a written language.  Just as ancient
  5090. Egyptian hieroglyphics is a written language.  But a language needs a
  5091. commonly recognized vocabulary to be decipherable.  Until we have one, I
  5092. feel that it is almost always more appropriate to use the local language
  5093. of choice.
  5094.  
  5095. Cheers,
  5096. Rob
  5097. _____________________________________________________________________
  5098. Robert S. Mah           Software Development          +1.212.947.6507
  5099. One Step Beyond        and Network Consulting          rmah@panix.com
  5100.  
  5101. +++++++++++++++++++++++++++
  5102.  
  5103. >From Jaeger@fquest.com (Brian Stern)
  5104. Date: 21 Aug 1994 21:02:27 GMT
  5105. Organization: The University of Texas at Austin, Austin, Texas
  5106.  
  5107. In article <rmah-2108941447560001@rmah.dialup.access.net>, rmah@panix.com
  5108. (Robert Mah) wrote:
  5109. [snip]
  5110. > So, finally, I would like to stress that it's not toolbars, per se, that
  5111. > bother me, it's the gratuitous use of babbeling icons to represent actions
  5112. > (i.e. verbs) without regard for standardization.
  5113. > The icons used in these buttons ARE a written language.  Just as ancient
  5114. > Egyptian hieroglyphics is a written language.  But a language needs a
  5115. > commonly recognized vocabulary to be decipherable.  Until we have one, I
  5116. > feel that it is almost always more appropriate to use the local language
  5117. > of choice.
  5118. > Cheers,
  5119. > Rob
  5120. > _____________________________________________________________________
  5121. > Robert S. Mah           Software Development          +1.212.947.6507
  5122. > One Step Beyond        and Network Consulting          rmah@panix.com
  5123.  
  5124. I think what this comes down to is problems with the replacement of text
  5125. with graphics.  
  5126.  
  5127. Consider the icons (or pictographs) at the tops of the reply windows in
  5128. NewsWatcher and Eudora.  In these cases icons are used to replace the text
  5129. in checkboxes.  The Newswatcher one works for me because there are only
  5130. three icons.  Interestingly, the Send function is accomplished by a
  5131. standard pushbutton with text in it.  The icons in Eudora's reply window
  5132. never worked for me because I never could figure out what they all meant
  5133. and I only used the program occasionally.
  5134.  
  5135. Consider also the icons in alert boxes.  These can't be manipulated in any
  5136. way.  They just convey the meaning of 'Warning' or 'here's something you
  5137. should know'.  This works because there are relatively few different alert
  5138. icons.  Imagine a program with a different alert icon for each error
  5139. message.
  5140.  
  5141. So what we're seeing is the replacement of text with graphics in a number
  5142. of places.  I do agree that it is usually more difficult to describe a
  5143. verb with a graphic than it is to describe a noun with a graphic.  I
  5144. think, again, that the problem is one of ease of remembering and ease of
  5145. figuring out.  
  5146.  
  5147. OTOH, what about command key equivalents.  At first blush it would seem
  5148. that pictures are better at describing actions than random letters. 
  5149. However, noone complains that command key equivalents are 'bad'.  I guess
  5150. part of it is that you can always look up the meaning of a command key
  5151. equivalent by pulling down the menus, and another part is that they are
  5152. completely unobtrusive if you don't use them.
  5153.  
  5154. I think you're right that there needs to be some standardization [hey we
  5155. got back to the title of this thread] of icons for use in place of text. 
  5156. It won't be easy though.  And tool palettes are too sexy for most
  5157. developers to think twice about not implementing them wherever they can.
  5158.  
  5159. -- 
  5160. Brian  Stern  :-{)}
  5161. Jaeger@fquest.com
  5162.  
  5163. +++++++++++++++++++++++++++
  5164.  
  5165. >From heilmayr@uclink.berkeley.edu (Klaus)
  5166. Date: 21 Aug 1994 23:16:27 GMT
  5167. Organization: Parentheses and Ellipses
  5168.  
  5169. In article <tgaul-2008940046270001@bellevue-ip27.halcyon.com>
  5170. tgaul@halcyon.com (Troy Gaul) writes:
  5171.  
  5172. > As for the comments about the design of the new AppleCD Audio Player, I
  5173. > don't find that as offensive as some of the other people who've commented
  5174. > on it.  The main reason I feel this way is that this is what I'll call a
  5175. > 'consumer interface' program (it's designed to look more like a 'real' CD
  5176. > Player's control panel).
  5177.  
  5178. When you're playing a CD, you see a lit-up "pause" control.  When you have a
  5179. CD paused, you see a lit-up "play" control instead.  Rather unlike a 'real' CD
  5180. player, in which the lit-up control is the one that's currently active (e.g.
  5181. when you're playing a CD, the "play" control is lit up).  This violates
  5182. another principle of user interface design: If you make changes to an
  5183. interface, those changes should be obvious.  You should never have a
  5184. familiar-looking interface element perform an unexpected function.
  5185.  
  5186.  -Klaus (heilmayr@math.berkeley.edu)
  5187.  
  5188. +++++++++++++++++++++++++++
  5189.  
  5190. >From hvoth@news.etc.bc.ca (Herb Voth)
  5191. Date: Mon, 22 Aug 1994 03:09:38 GMT
  5192. Organization: Ministry of Education
  5193.  
  5194. The way I see this button problem is this:
  5195.  
  5196. -MS basically duplicated all their menu and key combo features in buttons.
  5197. This can never be intuitive because there are too many options to
  5198. remember. Whoever decided that we needed a 'cut' button was more
  5199. interested in the gee whiz MTV factor than productivity. The fact that MS
  5200. has advertised the hell out of it, calling it productive does not make it so.
  5201.  
  5202. -MS changed the metaphor that was introduced with MacPaint where buttons
  5203. basically changed the context of editing a document. The buttons were more
  5204. like tools. MS decided that menus were dumb and has basically made them
  5205. redundant rather than complementing them the way MacPaint did.
  5206.  
  5207. -Programs are getting so feature rich that MS's metaphor of implementing
  5208. all features in buttons is a diminishing return, very short-sighted
  5209. interface. Having 15 button bars is not productive, it just sells 21"
  5210. monitors.
  5211.  
  5212. -People (who pay our salaries, of course) want buttons. So, we must
  5213. implement them. For them to be useful, they must be customizable. And,
  5214. *most importantly* they must be able to be hidden. As such, they must be
  5215. only one way of accessing each feature. I hate it when I have to turn on a
  5216. button bar just to access a feature.
  5217.  
  5218. -How about a button bar that appears when you press CTRL?
  5219.  
  5220. -Randall
  5221.  
  5222. -- 
  5223.  
  5224. +++++++++++++++++++++++++++
  5225.  
  5226. >From hanrek@cts.com (Mark Hanrek)
  5227. Date: 22 Aug 1994 04:25:07 GMT
  5228. Organization: The Information Workshop
  5229.  
  5230. In article <Cuv7Hz.79E@world.std.com>, ari@world.std.com (Ari I
  5231. Halberstadt) wrote:
  5232.  
  5233. > For me, it's not 7.5. It's the pathetic state of the APIs and
  5234. > documentation. Who wants to spend their life looking through 16000
  5235. > pages? There is no reason the OS needs to be that complicated. And no,
  5236. > a legacy OS is not a reason for rampant complexity. And OpenDoc is
  5237. > only going to make it worse. Oh ya, and six (SIX!!!) books for QDGX.
  5238. > Geesh.
  5239. > And then, there are the development tools. We all know what sorry
  5240. > state they've been in and continue to be in. And the pathetic
  5241. > languages used for development (this isn't a mac-only problem; none of
  5242. > this is a mac-only problem).
  5243.  
  5244. Ari,
  5245.  
  5246. I agree with your assessment 100%.  
  5247.  
  5248. I have come to discover that one of the reasons things are this way is
  5249. because programmers aren't as demanding as they could/should be.  
  5250.  
  5251. A majority accept things too easily, and adapt to the way things are too
  5252. easily.  
  5253.  
  5254. Often, programmers figure that if they don't understand something, it is
  5255. their fault, and then won't say anything.
  5256.  
  5257. Our tools ARE pretty crummy, yet look at the amazing and sophisticated
  5258. things we create with them routinely for others.  
  5259.  
  5260. Why don't we want tools that are equally sophisticated?  Why do we put
  5261. ourselves through building fine creations with just a screwdriver and a
  5262. hammer? :)
  5263.  
  5264. - ---
  5265.  
  5266. It reminds me of the "typical" mechanic, who can fix and tweak your car
  5267. and make it sing, but his car runs like ****.   :)
  5268.  
  5269. Likewise, programmers build the eWorlds, and the First Class BBSs, and
  5270. slick collaborative groupware for those how know it is a competitive
  5271. must...
  5272.  
  5273. ... but for some reason programmers find the less-than-primitive nature of
  5274. the internet newsgroup to be "just fine" for discussing sophisticated
  5275. technologies and rearing their young. 
  5276.  
  5277.  
  5278. Amazing, ain't it?
  5279.  
  5280. Mark Hanrek
  5281. The Information Workshop
  5282.  
  5283. +++++++++++++++++++++++++++
  5284.  
  5285. >From h+@nada.kth.se (Jon W{tte)
  5286. Date: Mon, 22 Aug 1994 09:24:36 +0200
  5287. Organization: Royal Institute of Something or other
  5288.  
  5289. In article <Jaeger-2108940750160001@slip-8-16.ots.utexas.edu>,
  5290. Jaeger@fquest.com (Brian Stern) wrote:
  5291.  
  5292. >Clicking on the pencil button does mean 'use the pencil now', and that's
  5293. >an action, not a noun.  If a graphics program was to maintain the Finder's
  5294.  
  5295. Now it's getting interesting.
  5296.  
  5297. Clicking on a pencil BUTTON would mean "use the pencil now" 
  5298. which is giving a command.
  5299.  
  5300. However, picking up a pencil from a palette (toolbox) would be 
  5301. akin to doing just that, physically, in the real world; picking 
  5302. up a pencil out of a toolbox, and there the pencil tool is most 
  5303. definately a noun.
  5304.  
  5305. These are two ways of using icons that differ subtly. I hope 
  5306. that subtlety doesn't get lost in a noise of toolbars...
  5307.  
  5308. Cheers,
  5309.  
  5310.                 / h+
  5311.  
  5312.  
  5313. --
  5314.   Jon W‰tte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden
  5315.     Not speaking for the Microsoft Corporation.
  5316.  
  5317.  
  5318. +++++++++++++++++++++++++++
  5319.  
  5320. >From siddoway@ee.utah.edu (Derick Siddoway)
  5321. Date: 22 Aug 1994 07:58:52 GMT
  5322. Organization: University of Utah
  5323.  
  5324. In article <Cuv7Hz.79E@world.std.com>
  5325. ari@world.std.com (Ari I Halberstadt) writes:
  5326.  
  5327. > Here's my schpiel: computers suck. They all suck.
  5328.  
  5329. Spiel?  That's my *mantra*.
  5330.  
  5331. - ---------
  5332. Derick H. Siddoway                __o      If you stew cranberries like
  5333. siddoway@ee.utah.edu            _>\<,_     applesauce, they taste much
  5334. University of Utah             (_)/ (_)    more like plums than rhubarb
  5335. Department of Electrical Engineering       does.  - (Groucho Marx) -
  5336.  
  5337. +++++++++++++++++++++++++++
  5338.  
  5339. >From Jaeger@fquest.com (Brian Stern)
  5340. Date: 22 Aug 1994 11:25:06 GMT
  5341. Organization: The University of Texas at Austin, Austin, Texas
  5342.  
  5343. In article <9668AA7E1F54.3CFD6E@klkmac014.nada.kth.se>, h+@nada.kth.se
  5344. (Jon W{tte) wrote:
  5345.  
  5346. > In article <Jaeger-2108940750160001@slip-8-16.ots.utexas.edu>,
  5347. > Jaeger@fquest.com (Brian Stern) wrote:
  5348. > >Clicking on the pencil button does mean 'use the pencil now', and that's
  5349. > >an action, not a noun.  If a graphics program was to maintain the Finder's
  5350. > Now it's getting interesting.
  5351. > Clicking on a pencil BUTTON would mean "use the pencil now" 
  5352. > which is giving a command.
  5353. > However, picking up a pencil from a palette (toolbox) would be 
  5354. > akin to doing just that, physically, in the real world; picking 
  5355. > up a pencil out of a toolbox, and there the pencil tool is most 
  5356. > definately a noun.
  5357. > These are two ways of using icons that differ subtly. I hope 
  5358. > that subtlety doesn't get lost in a noise of toolbars...
  5359. > Cheers,
  5360. >                                 / h+
  5361. > --
  5362. >   Jon W‰tte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden
  5363. >     Not speaking for the Microsoft Corporation.
  5364.  
  5365. In thinking about this some more, and looking at a graphics program, I've
  5366. realized that some of these tool pallettes are actually groups of
  5367. radiobuttons.  You have a bunch of choices, from which you can only choose
  5368. one, and that selection remains hilited.  Choosing one changes the
  5369. channel, if you will.  
  5370.  
  5371. So all three of the standard Mac text-based controls can also be rendered
  5372. graphically: pushbuttons, radiobuttons, and checkboxes.  (Scrollbars were
  5373. always graphical.)
  5374.  
  5375. Most of the graphics on word-processor toolbars are pushbuttons, with the
  5376. exception of a few radiobuttons.  Things like line spacing and text
  5377. justification are really radiobuttons, and these properties are really
  5378. adjectives: singlespaced, left justified etc.
  5379.  
  5380. I don't think that there is much confusion about this noun/verb/adjective
  5381. thing, however.  For one thing the pushbutton analogues are drawn as
  5382. buttons; they have a drop shadow and they move when pushed.  The graphical
  5383. checkboxes in Newswatcher and Eudora check and uncheck themselves when
  5384. clicked.  The graphical radio buttons hilite one of the choices at all
  5385. times and change in an obvious way when clicked.  The fact that these are
  5386. implemented as icons really isn't important, because they really do look
  5387. different and act differently from each other enough so that the user can
  5388. intuitively figure out how they work.  
  5389.  
  5390. The problem is the difficulty in figuring out what a particular graphic
  5391. represents without having the text as a reminder.  Perhaps liberal use of
  5392. ballon help would give us the best of both worlds.
  5393.  
  5394. -- 
  5395. Brian  Stern  :-{)}
  5396. Jaeger@fquest.com
  5397.  
  5398. +++++++++++++++++++++++++++
  5399.  
  5400. >From Willie Abrams <willie-abrams@uokhsc.edu>
  5401. Date: 22 Aug 1994 13:36:19 GMT
  5402. Organization: OU Health Sciences Center
  5403.  
  5404. In article <3331t7$rc8@falcon.bgsu.edu> bgsuvax, dnebing@andy.bgsu.edu
  5405. writes:
  5406. >  Take for example Word's toolbar that can be found in most of
  5407. >their apps now and can also be found in other vendor's apps
  5408. >(i.e. CodeWarrior).  The HIGs never evolved to encompass
  5409. >toolbars, hence the thread that started here some time back
  5410. >about toolbar icons representing nouns or verbs, and which
  5411. >was appropriate.
  5412.  
  5413. Toolbars are not cool, or good, or even mildly redeeming. 
  5414. Come on, please, the goal of any good UI is to get the hell
  5415. out of the users way so that they can get their work done.
  5416.  
  5417. The icons in Toolbars don't make sense. They aren't consistent.
  5418. And why do I need a toolbar icon to save, open or cut, copy,
  5419. paste, etc. Ugh. I don't highlight an icon in the Finder and
  5420. click on a "copy" icon, why the heck should I want to in a
  5421. word processor or compiler.
  5422.  
  5423. Toolbars are not quickly removed or added, rarely are they
  5424. resizeable, and they almost always go horizontal. (Damnit,
  5425. most monitors are landscape oriented - now I have to decrease
  5426. even further my vertical space? No.)
  5427.  
  5428. I can't move'm, reshape them, nor can I tell what is going on
  5429. in my compiles without it being there.
  5430.  
  5431. And from the looks of it, Word 6 with all of its damn toolbars,
  5432. will be better known as "Honey, I shrunk the document window!"
  5433.  
  5434.  
  5435. Willie Abrams                                  willie-abrams@uokhsc.edu
  5436. Telemedicine Software Guy                     OU Health Sciences Center
  5437.  
  5438. It's a classic Pincer's Movement. It can't fail against a ten-year-old!
  5439.  
  5440. +++++++++++++++++++++++++++
  5441.  
  5442. >From pcastine@prz.tu-berlin.de (Peter Castine)
  5443. Date: Mon, 22 Aug 1994 15:51:32 GMT
  5444. Organization: Process Control Center
  5445.  
  5446. In article <gurgle-1908941949000001@gurgle.dnai.com>, gurgle@dnai.com
  5447. (Pete Gontier) wrote:
  5448.  
  5449. > > While most programmers have followed the guidelines, there
  5450. > > are several apps out there that have had to break the HIGs
  5451. > > in order to do what was necessary.
  5452. > Examples being?
  5453.  
  5454. How about Pop-Up menus. Was a time, there was no such thing in HIG. I seem
  5455. to remember seeing them for the first time in dBase for Mac. Several
  5456. developers followed suit, the idea caught on, and pop-ups were canonized
  5457. in the HI chapter of IM IV. Hierarchical submenus were also officially
  5458. introduced in IM IV, but I'm sure that a couple of apps had introduced
  5459. this trick before it was ``canonized''.
  5460.  
  5461. Same for tri-state checkboxes. There's a human interface note that
  5462. acknowledges the appropriateness of tri-state objects and discusses the
  5463. solution used for menus that show state information (to wit, the Labels
  5464. menu in the Finder when the selected objects have different labels). The
  5465. note does not directly deal with the solution found in Microsoft products,
  5466. which, IMHO, is at least as good as the suggestion proposed in the note.
  5467.  
  5468. Facit: The Human Interface needs to grow (cf. _Macintosh Human Interface
  5469. Guidelines_, pp 38-40). As the book says, changes should be made
  5470. _cautiously_, with user testing and a sense of aesthetic compatibility
  5471. with the existing interface elements. 
  5472.  
  5473. There should be compelling reasons for developing a new interface element.
  5474. Changes should not be made arbitrarily.
  5475.  
  5476. -- 
  5477. Peter Castine               | C (n.): A programming language that is sort of
  5478. pcastine@prz.tu-berlin.de   | like Pascal except more like assembly except
  5479. Process Control Center      | that it isn't very much like either one, or
  5480. Technical University Berlin | anything else.                  -- Ray Simard
  5481.  
  5482. +++++++++++++++++++++++++++
  5483.  
  5484. >From dnebing@andy.bgsu.edu (bgsuvax)
  5485. Date: 22 Aug 1994 16:46:48 GMT
  5486. Organization: Bowling Green State University
  5487.  
  5488. Willie Abrams <willie-abrams@uokhsc.edu> writes:
  5489. > Toolbars are not cool, or good, or even mildly redeeming. 
  5490. > Come on, please, the goal of any good UI is to get the hell
  5491. > out of the users way so that they can get their work done.
  5492.  
  5493.   For some of the Word commands they do act as shortcuts, and
  5494. they increase my productivity in those situations.
  5495. > The icons in Toolbars don't make sense. They aren't consistent.
  5496. > And why do I need a toolbar icon to save, open or cut, copy,
  5497. > paste, etc. Ugh. I don't highlight an icon in the Finder and
  5498. > click on a "copy" icon, why the heck should I want to in a
  5499. > word processor or compiler.
  5500.  
  5501.   Yes, icons for cut & paste are pretty pointless.  But the
  5502. beauty behind Word's toolbar is that it is *CUSTOMIZABLE*.
  5503. You can take out the 'Save' icon and replace it with a
  5504. 'Save As' icon (for which there is either no keyboard command
  5505. equivalent or it is so esoteric that I can't ever remember it).
  5506. I don't set up the buttons for simple commands which the
  5507. keyboard equivalents are easily remembered.  I have buttons for
  5508. the ones that are (somewhat ;-) cryptic.  Granted, my settings
  5509. would confuse a newbie and also the icons that I have set for
  5510. the command hardly leave a clue as to what the command is, but
  5511. for me they make sense.
  5512.  
  5513. > Toolbars are not quickly removed or added, rarely are they
  5514. > resizeable, and they almost always go horizontal. (Damnit,
  5515. > most monitors are landscape oriented - now I have to decrease
  5516. > even further my vertical space? No.)
  5517.   These features are customizable in Word.  Verticle on either
  5518. side is OK.
  5519.  
  5520. > I can't move'm, reshape them, nor can I tell what is going on
  5521. > in my compiles without it being there.
  5522.   Maybe they don't make alot of sense in CodeWarrior (I haven't
  5523. seen them yet... ;-)  That doesn't mean they don't have a place
  5524. in UI design.
  5525.  
  5526. > And from the looks of it, Word 6 with all of its damn toolbars,
  5527. > will be better known as "Honey, I shrunk the document window!"
  5528.  
  5529.   And if the toolbars are similar to the 5.1 version, then they
  5530. will not only be customizable but hideable also.  That means that
  5531. if you don't want to see 'em you can make 'em go away.
  5532.  
  5533.   Now don't get me wrong, I am not a big MS fan.  I think they
  5534. are a huge Goliath that will fall to a smaller David (Apple? ;-)
  5535. someday.  But the goal of this thread was to discuss the HIGs
  5536. and why Apple was abandoning them in 7.5.  I brought up the
  5537. toolbar thing because there is a market for them, and the HIGs
  5538. don't cover toolbars (yet?).
  5539.  
  5540. Dave
  5541.  
  5542. ============================================================
  5543. Dave Nebinger                    dnebing@bgsuvax.bgsu.edu
  5544. Network Manager, Biology Dept.   dnebing@opie.bgsu.edu
  5545. Bowling Green State University   dnebing@bgsuopie (bitnet)
  5546. Bowling Green, OH 43403          #include <std_disclaimer.h>
  5547.  
  5548.              *THE* alt.sources.mac supporter!
  5549.  
  5550. +++++++++++++++++++++++++++
  5551.  
  5552. >From sichase@csa5.lbl.gov (SCOTT I CHASE)
  5553. Date: 22 Aug 1994 15:37 PST
  5554. Organization: Lawrence Berkeley Laboratory - Berkeley, CA, USA
  5555.  
  5556. In article <pcastine-1908941211190001@maggie.prz.tu-berlin.de>, pcastine@prz.tu-berlin.de (Peter Castine) writes...
  5557. >As one example, I was looking at the new(ish) AppleCD Audio Player. The
  5558. >only reason I even tried clicking on the little green triangle in the
  5559. >lower left corner was because I knew that the fore-runner software had a
  5560. >track list and I was sure that the newer software _must_ have a track list
  5561. >somewhere. I looked in the menus, to no avail, so I started clicking
  5562. >around and the mouse finally landed on said triangle. Voila! Success at
  5563. >last!
  5564. >So, in short: yes, this bothers me. Who else?
  5565.  
  5566. Me!  I just discovered this last night.  I was helping a friend set up 
  5567. her 840 AV.  Having never used an AV Mac before, I was having fun playing
  5568. with all the neat tools.  I fooled around with the AppleCD Audio Player
  5569. for at least 15 minutes before I accidentally, at random, hit that 
  5570. little green triangle.  That's a button?  Jeez.
  5571.  
  5572. -Scott
  5573. - ------------------                         Physics is not a religion.  If
  5574. Scott I. Chase                               it were, we'd have a much easier
  5575. SICHASE@CSA2.LBL.GOV                         time raising money. -Leon Lederman
  5576.  
  5577. +++++++++++++++++++++++++++
  5578.  
  5579. >From 103t_english@west.cscwc.pima.edu
  5580. Date: 22 Aug 94 16:44:49 MST
  5581. Organization: (none)
  5582.  
  5583. In article <33a9kj$504@romulus.ucs.uoknor.edu>, Willie Abrams <willie-abrams@uokhsc.edu> writes:
  5584. > In article <3331t7$rc8@falcon.bgsu.edu> bgsuvax, dnebing@andy.bgsu.edu
  5585. > writes:
  5586. >>  Take for example Word's toolbar that can be found in most of
  5587. >>their apps now and can also be found in other vendor's apps
  5588. >>(i.e. CodeWarrior).  The HIGs never evolved to encompass
  5589. >>toolbars, hence the thread that started here some time back
  5590. >>about toolbar icons representing nouns or verbs, and which
  5591. >>was appropriate.
  5592. > Toolbars are not cool, or good, or even mildly redeeming. 
  5593. > Come on, please, the goal of any good UI is to get the hell
  5594. > out of the users way so that they can get their work done.
  5595. > The icons in Toolbars don't make sense. They aren't consistent.
  5596. > And why do I need a toolbar icon to save, open or cut, copy,
  5597. > paste, etc. Ugh. I don't highlight an icon in the Finder and
  5598. > click on a "copy" icon, why the heck should I want to in a
  5599. > word processor or compiler.
  5600.  
  5601. The only place where "Toolbars" make sense is where they have always been:
  5602.  
  5603.  
  5604. rulers -a convenient way to control lots of little options that can change
  5605. drastically depending on where you are in your document.
  5606.  
  5607. Rulers (toolbars) in this case allow you to not only control the parameters of
  5608. the document but also get visual feedback as to what they are.
  5609.  
  5610.  
  5611. The only other use that makes sense, H-I-wise, is when you use a certain
  5612. menu-item a LOT that happens to be nested deep in a hierarchical menu. THEN you
  5613. want it to appear on the toolbar because it is more convenient than using the
  5614. menu, and is more consistent that rearranging the menu-order to suit your whim
  5615. for what may be a specialized need in a specific document.
  5616.  
  5617. Hmmm... Does Word even allow document specific toolbars?
  5618.  
  5619.  
  5620. Lawson
  5621.  
  5622. +++++++++++++++++++++++++++
  5623.  
  5624. >From chuck@molecule.Physics.Drexel.Edu (Chuck Browne)
  5625. Date: 23 Aug 1994 00:16:47 GMT
  5626. Organization: Drexel University (Computing Services)
  5627.  
  5628. SCOTT I CHASE (sichase@csa5.lbl.gov) wrote:
  5629. : In article <pcastine-1908941211190001@maggie.prz.tu-berlin.de>, pcastine@prz.tu-berlin.de (Peter Castine) writes...
  5630. : > 
  5631. : >As one example, I was looking at the new(ish) AppleCD Audio Player. The
  5632. : >only reason I even tried clicking on the little green triangle in the
  5633. : >lower left corner was because I knew that the fore-runner software had a
  5634. : >track list and I was sure that the newer software _must_ have a track list
  5635. : >somewhere. I looked in the menus, to no avail, so I started clicking
  5636. : >around and the mouse finally landed on said triangle. Voila! Success at
  5637. : >last!
  5638. : > 
  5639. : >So, in short: yes, this bothers me. Who else?
  5640.  
  5641. : Me!  I just discovered this last night.  I was helping a friend set up 
  5642. : her 840 AV.  Having never used an AV Mac before, I was having fun playing
  5643. : with all the neat tools.  I fooled around with the AppleCD Audio Player
  5644. : for at least 15 minutes before I accidentally, at random, hit that 
  5645. : little green triangle.  That's a button?  Jeez.
  5646.  
  5647.  
  5648. That got me too! I found it totally by accident - I saw the triangle,
  5649. and thought it was just a power LED, just like on a non-virtual stereo.
  5650. When I accidentally clicked on it and the track list opened, I got that
  5651. "Hey, this program is like Myst in the puzzles that delight" feeling...
  5652.  
  5653. Chuck
  5654.  
  5655. : -Scott
  5656. : --------------------                         Physics is not a religion.  If
  5657. : Scott I. Chase                               it were, we'd have a much easier
  5658. : SICHASE@CSA2.LBL.GOV                         time raising money. -Leon Lederman
  5659.  
  5660. +++++++++++++++++++++++++++
  5661.  
  5662. >From gewekean@student.msu.edu (Andrew Geweke)
  5663. Date: Mon, 22 Aug 1994 21:26:57 -0500
  5664. Organization: Michigan State University
  5665.  
  5666. In article <33a9kj$504@romulus.ucs.uoknor.edu>, Willie Abrams <willie-
  5667. abrams@uokhsc.edu> writes:
  5668. > In article <3331t7$rc8@falcon.bgsu.edu> bgsuvax, dnebing@
  5669. > andy.bgsu.edu writes: 
  5670. > >  Take for example Word's toolbar that can be found in most of 
  5671. > >their apps now and can also be found in other vendor's apps 
  5672. > >(i.e. CodeWarrior).  The HIGs never evolved to encompass toolbars, 
  5673. > >hence the thread that started here some time back about toolbar 
  5674. > >icons representing nouns or verbs, and which was appropriate. 
  5675. >  
  5676. > Toolbars are not cool, or good, or even mildly redeeming. 
  5677. > Come on, please, the goal of any good UI is to get the hell out of 
  5678. > the users way so that they can get their work done. 
  5679.  
  5680. Amen. Doesn't *anybody* here like the kind of application where you get one 
  5681. big window to work on your document that takes up all of your monitor? 
  5682. (Assuming, of course, the document's natural size is at least that big? :-)
  5683.  
  5684. > The icons in Toolbars don't make sense. They aren't consistent. 
  5685. > And why do I need a toolbar icon to save, open or cut, copy, paste, 
  5686. > etc. Ugh. I don't highlight an icon in the Finder and click on a 
  5687. > "copy" icon, why the heck should I want to in a word processor or 
  5688. > compiler. 
  5689.  
  5690. You shouldn't, obviously.
  5691.  
  5692. Here's the major sticking point, too: Toolbars may or may not be an advantage 
  5693. for the first-time user. (I tend to think they aren't.) However, they are a *
  5694. disadvantage* for anybody familiar with the program. Try this: Do these three 
  5695. things, and see which is fastest. (1) Hit a command key for a menu command. 
  5696. (I'm assuming you're at least a competent touch-typist). (2) Pull down the 
  5697. menu to that command. (3) Find the toolbar button for that command and click 
  5698. it.
  5699.  
  5700. Unless the toolbar buttons are at least 40x40 pixels, I think (2) is probably 
  5701. faster than (3). (1) is by far the fastest.
  5702.  
  5703. In Windows, where every last app has a different key shortcut for Cut, Copy, 
  5704. and Paste, toolbars may make sense; however, on the Mac, Command-X flies off 
  5705. my fingertips while (find the right button) -> (maneuver to the tiny button) -
  5706. > (click the button) takes forever.
  5707.  
  5708. And finally, of course, as Apple has pointed out, menus have an "infinite" 
  5709. height. I've got NowMenus set to automatically pull menus for me and leave 
  5710. them down. I shove the mouse up to the top of the screen and bang, I've got 
  5711. menus. It takes almost no effort at all.
  5712.  
  5713. > And from the looks of it, Word 6 with all of its damn toolbars, will 
  5714. > be better known as "Honey, I shrunk the document window!" 
  5715.  
  5716. No shit. Excel 4 is already bad enough. C'mon, let's all cheer on WordPerfect!
  5717.  
  5718. Cheers,
  5719. Andrew
  5720.  
  5721.  
  5722.  
  5723.  
  5724.  
  5725. +++++++++++++++++++++++++++
  5726.  
  5727. >From tgaul@halcyon.com (Troy Gaul)
  5728. Date: Mon, 22 Aug 1994 23:33:18 -0700
  5729. Organization: Infinity Systems
  5730.  
  5731. In article <9408222126.AA57236@geweke.ppp.msu.edu>,
  5732. gewekean@student.msu.edu (Andrew Geweke) wrote:
  5733.  
  5734. > Here's the major sticking point, too: Toolbars may or may not be an advantage 
  5735. > for the first-time user. (I tend to think they aren't.) However, they are a *
  5736. > disadvantage* for anybody familiar with the program. Try this: Do these three 
  5737. > things, and see which is fastest. (1) Hit a command key for a menu command. 
  5738. > (I'm assuming you're at least a competent touch-typist). (2) Pull down the 
  5739. > menu to that command. (3) Find the toolbar button for that command and click 
  5740. > it.
  5741. > Unless the toolbar buttons are at least 40x40 pixels, I think (2) is probably 
  5742. > faster than (3). (1) is by far the fastest.
  5743.  
  5744. Not true.  Often, (except for the highly consistent, often used command
  5745. key shortcuts like cut, copy, paste, save, etc) it is either just as fast
  5746. or faster to use a menu as it is to use a key command that corresponds
  5747. with it.
  5748.  
  5749. I don't want to go into all the details here because it is described in
  5750. the book _Tog On Interface_.  A couple relavent quotes, from page 26:
  5751.  
  5752. "We discovered, among other things, two pertinent facts:
  5753.  
  5754.   -- Test subjects consistently report that keyboarding is faster than mousing.
  5755.  
  5756.   -- The stopwatch consistently proves mousing is faster than keyboarding.
  5757.  
  5758.   The contradiction between user-experience and reality apparently forms
  5759. the basis for many user/developers' belief that the keyboard is faster."
  5760.  
  5761. The difference is that using the mouse to issue a command doesn't require
  5762. "high-level cognitive engagement" and is in fact "boring", according to
  5763. Tog.  Deciding what command keys ("abstract symbols") to use is a
  5764. "high-level cognitive function."  He goes on to say that, "Not only is
  5765. this decision not boring, the user actually experiences amnesia!  *Real*
  5766. amnesia!  The time-slice spent making the decision simply ceases to
  5767. exist."
  5768.  
  5769. Before you argue, please read the rest of this interesting article from
  5770. Tog's book.  It was also in the Apple Direct (or whatever it was called
  5771. then) magazine in August of 1989.
  5772.  
  5773.  
  5774. Now, when you think of the action in these terms, using a toolbar to
  5775. execute a command becomes a similar kind of "high-level cognitive
  5776. function."  This means that your mind is engaged in finding the icon that
  5777. represents the action you want to perform, and the same sort of rules
  5778. would seem to apply.  
  5779.  
  5780. Now, as we all know, for some common actions, key commands are actually
  5781. faster than the mouse (for example, when demoing products, I've tried
  5782. using key commands for undo, cut, copy and paste, and it was always much
  5783. more difficult than using the keys).  
  5784.  
  5785. In a similar fashion, for those people who decide to use a toolbar, I'm
  5786. sure that there are commands that they learn the positions/appearances of
  5787. in a similar fashion so as to be useful.  For instance, while generally
  5788. against toolbars, I do use the Metrowerks toolbar to issue the Run and
  5789. Preferences commands.  The majority of the others go unused, though.
  5790.  
  5791.  
  5792. > > And from the looks of it, Word 6 with all of its damn toolbars, will 
  5793. > > be better known as "Honey, I shrunk the document window!" 
  5794. > C'mon, let's all cheer on WordPerfect!
  5795.  
  5796. Which would be a good time to point out that WordPerfect has its own
  5797. version of 'toolbar hell', which occurs when you lose over half of your
  5798. screen if you show all of its toolbars simultaneously.  However, it does
  5799. so in a way that seems (to me as someone who hasn't actually _used_ the
  5800. program) like a much better scheme.
  5801.  
  5802. You basically have one bar that lets you access the others given on the
  5803. type of actions you wish to perform (by name, not icon you'll notice).  It
  5804. doesn't really fit the definition of toolbar as is being discussed in this
  5805. article, as these are sets of controls, not only icons, that are grouped
  5806. for doing things like changing text font, alignment, etc.
  5807.  
  5808. If I did much word processing, I'd try it out to see if it's as good an
  5809. idea as it looks.
  5810.  
  5811. Oh, and one last parting shot: I've noticed that other complex
  5812. applications, including Photoshop, Illustrator, Freehand, PageMaker, Quark
  5813. Xpress, and many others get by fine without using toolbars at all.  Just
  5814. think of what life would be like if every program had a toolbar, with a
  5815. separate set of icons, commands, etc. (Makes me think of Windows,
  5816. actually...)
  5817.  
  5818. _troy
  5819. //////// //////___Troy Gaul____________________tgaul@halcyon.com___//
  5820.   //    //      Infinity Systems                                  //
  5821.  //    //  //  Redmond, Washington                               //
  5822. //    //////____________________________________________________//
  5823.  
  5824. +++++++++++++++++++++++++++
  5825.  
  5826. >From zstern@adobe.com (Zalman Stern)
  5827. Date: Tue, 23 Aug 1994 12:16:59 GMT
  5828. Organization: Adobe Systems Incorporated
  5829.  
  5830. Troy Gaul writes
  5831. > Oh, and one last parting shot: I've noticed that other complex
  5832. > applications, including Photoshop, Illustrator, Freehand, PageMaker, Quark
  5833. > Xpress, and many others get by fine without using toolbars at all.  Just
  5834. > think of what life would be like if every program had a toolbar, with a
  5835. > separate set of icons, commands, etc. (Makes me think of Windows,
  5836. > actually...)
  5837.  
  5838. We have something called the "toolbar pact" among the Photoshop engineering  
  5839. team. Collectively, we will stop at nothing to prevent toolbars from  
  5840. creeping into the app. On the other hand the reward for adding a cool new  
  5841. floating palette is at least a free beer. Go figure :-)
  5842. --
  5843. Zalman Stern           zalman@adobe.com            (415) 962 3824
  5844. Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
  5845.  Please do not change color while I am talking to you -- MC 900 Ft Jesus.
  5846.  
  5847. +++++++++++++++++++++++++++
  5848.  
  5849. >From dnebing@andy.bgsu.edu (bgsuvax)
  5850. Date: 23 Aug 1994 14:34:48 GMT
  5851. Organization: Bowling Green State University
  5852.  
  5853. 103t_english@west.cscwc.pima.edu writes:
  5854. > The only place where "Toolbars" make sense is where they have always been:
  5855. > The only other use that makes sense, H-I-wise, is when you use a certain
  5856. > menu-item a LOT that happens to be nested deep in a hierarchical menu. THEN you
  5857. > want it to appear on the toolbar because it is more convenient than using the
  5858. > menu, and is more consistent that rearranging the menu-order to suit your whim
  5859. > for what may be a specialized need in a specific document.
  5860.   How about when an app (like Word) has so many menu items that the
  5861. frequently used menu items are far down in the menu, so far that the
  5862. menu has to scroll?
  5863.  
  5864. > Hmmm... Does Word even allow document specific toolbars?
  5865.   No, but you can configure it to contain customized commands.
  5866.  
  5867.   Dave
  5868.  
  5869.   (p.s. Down with MicroSoft [i.e. I am not an MS-lover!] ;-)
  5870.  
  5871. ============================================================
  5872. Dave Nebinger                    dnebing@bgsuvax.bgsu.edu
  5873. Network Manager, Biology Dept.   dnebing@opie.bgsu.edu
  5874. Bowling Green State University   dnebing@bgsuopie (bitnet)
  5875. Bowling Green, OH 43403          #include <std_disclaimer.h>
  5876.  
  5877.              *THE* alt.sources.mac supporter!
  5878.  
  5879. +++++++++++++++++++++++++++
  5880.  
  5881. >From dnebing@andy.bgsu.edu (bgsuvax)
  5882. Date: 23 Aug 1994 14:46:32 GMT
  5883. Organization: Bowling Green State University
  5884.  
  5885. gewekean@student.msu.edu (Andrew Geweke) writes:
  5886. > Try this: Do these three 
  5887. > things, and see which is fastest. (1) Hit a command key for a menu command. 
  5888. > (I'm assuming you're at least a competent touch-typist). (2) Pull down the 
  5889. > menu to that command. (3) Find the toolbar button for that command and click 
  5890. > it.
  5891. > Unless the toolbar buttons are at least 40x40 pixels, I think (2) is probably 
  5892. > faster than (3). (1) is by far the fastest.
  5893.  
  5894.   I have one example which will prove you wrong.  On my Word toolbar,
  5895. I have customized the toolbar.  One of the icons I have set up as
  5896. the little paintbrush, and the command associated with it is
  5897. 'Insert Graphic'.  There is no key command normally associated with
  5898. this command.  It is also far down the menu so that I have to scroll
  5899. to get to it.  In this situation, the icon is easy to identify and is
  5900. much faster than trying to get to the menu.
  5901.  
  5902.   It is not always the case that toolbars are either good or bad.
  5903. It is a personal preference, just like picking a big-blue box or
  5904. a Mac.  So whether you like them or you don't is not the question.
  5905. How the HIGs should standardize them is the question.
  5906.  
  5907. Dave
  5908.  
  5909. ============================================================
  5910. Dave Nebinger                    dnebing@bgsuvax.bgsu.edu
  5911. Network Manager, Biology Dept.   dnebing@opie.bgsu.edu
  5912. Bowling Green State University   dnebing@bgsuopie (bitnet)
  5913. Bowling Green, OH 43403          #include <std_disclaimer.h>
  5914.  
  5915.              *THE* alt.sources.mac supporter!
  5916.  
  5917. +++++++++++++++++++++++++++
  5918.  
  5919. >From mxmora@unix.sri.com (Matt Mora)
  5920. Date: 23 Aug 1994 08:07:03 -0700
  5921. Organization: SRI International, Menlo Park, CA
  5922.  
  5923. In article <tgaul-2008940046270001@bellevue-ip27.halcyon.com> 
  5924. tgaul@halcyon.com (Troy Gaul) writes:
  5925.  
  5926. >Anyway, I'd like to hear from some of the Apple people who are on the list
  5927. >as to how this stuff goes on.  How do these designs get into products?  I
  5928. >understand that there was one person in particular who did most of the
  5929. >designs for the color icons when System 7 was released, why isn't there a
  5930. >similar person who could enforce some amount of user interface
  5931. >consistency?
  5932.  
  5933. Apple doesn't write all of its own software. For example Apple Guide
  5934. was written by a third party. That third party is the one who
  5935. wrote the IDE drivers for the new computers I believe.
  5936.  
  5937. That's just two cases that I know about. Looks like 7.5 is full
  5938. of Third Party stuff. Why they didn't include your WDEF is 
  5939. beyond me. 
  5940.  
  5941.  
  5942. >//////// //////___Troy Gaul____________________tgaul@halcyon.com___//
  5943. >  //    //      Infinity Systems                                  //
  5944. > //    //  //  Redmond, Washington                               //
  5945.                 ^^^^^^^^^^^^^^^^^^^
  5946. Getting to close to the evil empire eh? Can you feel the dark side
  5947. of the force? Obiwan may be your only hope. :-)
  5948.  
  5949.  
  5950.  
  5951.  
  5952.  
  5953. Xavier
  5954.  
  5955. -- 
  5956. ___________________________________________________________
  5957. Matthew Xavier Mora                       Matt_Mora@sri.com
  5958. SRI International                       mxmora@unix.sri.com
  5959. 333 Ravenswood Ave                    Menlo Park, CA. 94025
  5960.  
  5961. +++++++++++++++++++++++++++
  5962.  
  5963. >From mxmora@unix.sri.com (Matt Mora)
  5964. Date: 23 Aug 1994 08:19:51 -0700
  5965. Organization: SRI International, Menlo Park, CA
  5966.  
  5967. In article <hanrek-2008941839270001@auke.cts.com> hanrek@cts.com (Mark Hanrek) writes:
  5968. >Maybe that analogy is useful in this discussion.
  5969. >
  5970. >Today, we can get into a 1965 Galaxie 500, or a 1994 Supra, and easily
  5971. >know what to do to drive either of them.
  5972.  
  5973. But do you know how to turn on the lights or High Beams? What about
  5974. air conditioning? When ever you get into a car you never been in before
  5975. it takes a while to find out where these things are and how they work.
  5976. When car companies started using icons it got worse.
  5977.  
  5978.  
  5979. Xavier
  5980.  
  5981.  
  5982.  
  5983.  
  5984.  
  5985. -- 
  5986. ___________________________________________________________
  5987. Matthew Xavier Mora                       Matt_Mora@sri.com
  5988. SRI International                       mxmora@unix.sri.com
  5989. 333 Ravenswood Ave                    Menlo Park, CA. 94025
  5990.  
  5991. +++++++++++++++++++++++++++
  5992.  
  5993. >From Willie Abrams <willie-abrams@uokhsc.edu>
  5994. Date: 23 Aug 1994 13:34:08 GMT
  5995. Organization: OU Health Sciences Center
  5996.  
  5997. In article <1994Aug23.121659.18750@adobe.com> Zalman Stern,
  5998. zstern@adobe.com writes:
  5999. >We have something called the "toolbar pact" among the Photoshop
  6000. engineering  
  6001. >team. Collectively, we will stop at nothing to prevent toolbars from  
  6002. >creeping into the app. On the other hand the reward for adding a cool
  6003. new  
  6004. >floating palette is at least a free beer. Go figure :-)
  6005.  
  6006. Good. I am happy. Maybe you all can start redesigning
  6007. that control palette in PageMaker.
  6008.  
  6009. Palettes are infinitely better than toolbars
  6010. as they are moveable (not just the sides of the screens),
  6011. easily closed (Wow, I can click the close box to make it go away.
  6012. What a concept!), and they follow function. I can sit down at
  6013. about any copy of Photoshop or Illustrator and work with
  6014. any users setup. This is because the palettes follow a particular
  6015. function, not just any arbitrary user configuration.
  6016.  
  6017. Toolbars were invented by Microsoft so that they wouldn't
  6018. have to do palettes. I refuse to accept a copout design as
  6019. standard interface, or even blessed HIG, when palettes simply
  6020. work better.
  6021.  
  6022. Willie Abrams                                  willie-abrams@uokhsc.edu
  6023. Telemedicine Software Guy                     OU Health Sciences Center
  6024.  
  6025. It's a classic Pincer's Movement. It can't fail against a ten-year-old!
  6026.  
  6027. +++++++++++++++++++++++++++
  6028.  
  6029. >From pat@postoffice.manassas.ibm.com (Pat LaVarre)
  6030. Date: 23 Aug 1994 17:32:59 GMT
  6031. Organization: Loral Federal Systems - Manassas, VA
  6032.  
  6033. Yea.  I think of a toolbar like a mini-desktop: a place where I can build my own
  6034. collection of data & tools.  For example, by putting a folder of aliases on the
  6035. desktop, I build a widget that works a lot like the Apple menu, without mucking
  6036. up the Apple menu that people generally expect. 
  6037.  
  6038. -- 
  6039. Pat LaVarre   p.lavarre@ieee.org
  6040. The ASCII punctuation set here is !"#$%&'()*+,-./ :;<=>?@ [\]^_` {|}~
  6041.  
  6042. +++++++++++++++++++++++++++
  6043.  
  6044. >From gbolsinga@aol.com (GBolsinga)
  6045. Date: 23 Aug 1994 14:40:12 -0400
  6046. Organization: America Online, Inc. (1-800-827-6364)
  6047.  
  6048. My two Cents:
  6049.  
  6050. I don't care if there are toolbars or not.  I just want to be able to get
  6051. rid of them if I want (which is usually true).
  6052.  
  6053. Greg
  6054. MPI Multimedia
  6055.  
  6056. +++++++++++++++++++++++++++
  6057.  
  6058. >From jonpugh@netcom.com (Jon Pugh)
  6059. Date: Tue, 23 Aug 1994 18:18:23 GMT
  6060. Organization: Will hack for food
  6061.  
  6062. Mark Hanrek (hanrek@cts.com) wrote:
  6063.  
  6064. > I have come to discover that one of the reasons things are this way is
  6065. > because programmers aren't as demanding as they could/should be.  
  6066.  
  6067. > A majority accept things too easily, and adapt to the way things are too
  6068. > easily.  
  6069.  
  6070. > Often, programmers figure that if they don't understand something, it is
  6071. > their fault, and then won't say anything.
  6072.  
  6073. > Our tools ARE pretty crummy, yet look at the amazing and sophisticated
  6074. > things we create with them routinely for others.  
  6075.  
  6076. > Why don't we want tools that are equally sophisticated?  Why do we put
  6077. > ourselves through building fine creations with just a screwdriver and a
  6078. > hammer? :)
  6079.  
  6080. I think the main reason is that we are more interested in creating than
  6081. complaining (except for whining on c.s.m.p of course ;).  I don't know
  6082. about you, but I've been under severe deadlines on my past 5 projects
  6083. and don't have time to whine about the tools.  I just try to find ones
  6084. that work and cope with it.
  6085.  
  6086. God, I love creating though.
  6087.  
  6088. Jon
  6089.  
  6090. +++++++++++++++++++++++++++
  6091.  
  6092. >From francis@pinza.demon.co.uk (Francis H Knight)
  6093. Date: Tue, 23 Aug 1994 21:53:37 GMT
  6094. Organization: Hertfordshire Mac Oasis
  6095.  
  6096. I tend to share the majority concern for the Mac's 'disippating' human
  6097. interface. I got to wondering what the simplest explanation for this
  6098. state of affairs might be. Knowing what that was could provide an
  6099. insight into the way to fix it.
  6100.  
  6101. I've come to the conclusion that in the battle with Macrosoft, Apple has
  6102. allowed Windows to close to a sufficiently short range that the most
  6103. effective tactical ammunition now is the 'bullet point'. Most consumers
  6104. seem easily swayed by what they see in the press, and a comparison of
  6105. feature lists is staple fare for computer journalists. 
  6106.  
  6107. On the surface, one of the best things about System 7.5 is the bundling
  6108. of MacTCP, but when you read that Chicago is slated to incorporate a TCP
  6109. stack, and to be promoted as 'Internet-Ready', or some such slogan, then
  6110. you could be forgiven for suspecting that Apple is now merely a reactive
  6111. organisation.
  6112.  
  6113. If there is a strategy to move out of range again, as opposed to a
  6114. tactic for short-term survival, then maybe OpenDoc is it. I just hope
  6115. it's not too radical for MIS types to contemplate embracing. I can
  6116. imagine them fearing facing a choice between an administrative nightmare
  6117. and software anarchy. UK MacUser has quotes from Microsoft who believe
  6118. these fears will work in their favour.
  6119.  
  6120.  
  6121.  
  6122. Francis
  6123.  
  6124. +++++++++++++++++++++++++++
  6125.  
  6126. >From 103t_english@west.cscwc.pima.edu
  6127. Date: 23 Aug 94 15:22:30 MST
  6128. Organization: (none)
  6129.  
  6130. In article <33d1e8$g64@falcon.bgsu.edu>, dnebing@andy.bgsu.edu (bgsuvax) writes:
  6131. > 103t_english@west.cscwc.pima.edu writes:
  6132. >> 
  6133. >> The only place where "Toolbars" make sense is where they have always been:
  6134. >> 
  6135. >> The only other use that makes sense, H-I-wise, is when you use a certain
  6136. >> menu-item a LOT that happens to be nested deep in a hierarchical menu. THEN you
  6137. >> want it to appear on the toolbar because it is more convenient than using the
  6138. >> menu, and is more consistent that rearranging the menu-order to suit your whim
  6139. >> for what may be a specialized need in a specific document.
  6140. >> 
  6141. >   How about when an app (like Word) has so many menu items that the
  6142. > frequently used menu items are far down in the menu, so far that the
  6143. > menu has to scroll?
  6144.  
  6145. Nested, long [scrolling] list, same bad design, IMHO...
  6146.  
  6147. >> Hmmm... Does Word even allow document specific toolbars?
  6148. >> 
  6149. >   No, but you can configure it to contain customized commands.
  6150.  
  6151. Decent. Does it allow Applscript-attachability/tinkerability to appear?
  6152.  
  6153. >   Dave
  6154. >   (p.s. Down with MicroSoft [i.e. I am not an MS-lover!] ;-)
  6155.  
  6156.  
  6157. MicroSoft-lovers don't admit to their bad habits in public (from the
  6158. undiscovered Notebooks of Lazurus Long)
  6159.  
  6160.  
  6161.  
  6162. Lawson
  6163.  
  6164. +++++++++++++++++++++++++++
  6165.  
  6166. >From Ross Scott Rubin <rrubin@sbi.com>
  6167. Date: Tue, 23 Aug 1994 23:01:43 GMT
  6168. Organization: Salomon Brothers Inc
  6169.  
  6170. In article <wysockiCus0pB.6KG@netcom.com> Chris Wysocki, wysocki@netcom.com
  6171. writes:
  6172. >I wholeheartedly concur.  Apple has done far too little in recent
  6173. >years to promote UI consistency across applications.  Their reluctance
  6174. >to provide standard implementations of UI features such as floating
  6175. >windows, menus with multiple-modifier keyboard shortcuts, and basic
  6176. >controls such as up-down arrows, sliders and progress bars have forced
  6177. >developers to implement these features themselves, with varying and
  6178. >sometimes inconsistent results.  At the Worldwide Developers
  6179. >Conference in May some Apple engineers spoke in nebulous terms about
  6180. >future UI enhancements which are coming down the road, but it struck
  6181. >me and others with whom I spoke as too little, too late....
  6182.  
  6183. An excellent response, Chris. I believe System 8 is supposed to restore
  6184. consistency toward creating a Mac interface in the world beyond the black
  6185. and white screen.
  6186.  
  6187. +-- +--\ --- ---------------------------------------------------------------+
  6188. |   |  /  | Ross Scott Rubin      | Internet: rrubin@sbi.com                |
  6189. +-+ +-<   | Salomon Brothers, Inc.| AOL, eWorld: rossrubin | CIS:72137,2627 |
  6190.   | |  \  |    "Opinions are mine alone. Who else would admit to them?"     |
  6191. --+ +--/ --- ---------------------------------------------------------------+
  6192.  
  6193. +++++++++++++++++++++++++++
  6194.  
  6195. >From Jens Alfke <jens_alfke@powertalk.apple.com>
  6196. Date: Wed, 24 Aug 1994 01:11:25 GMT
  6197. Organization: Apple Computer
  6198.  
  6199. netcom.com!kira!davidjohn,  writes:
  6200. > Individually, many of these don't look that bad, I suppose (but, that's  
  6201. > another issue, really).  However, as I recall, one of the advertised  
  6202. > strengths of the Macintosh, in past years, was its highly consistent  
  6203. > interface...
  6204.  
  6205. This discussion came up after WWDC when people were playing with the beta
  6206. version of 7.5. The fundamental issue is that the HI has to move forward;
  6207. that the old mostly black and white interface is getting old. Future system
  6208. software will have drastic changes, but there are incremental ones in 7.5.
  6209.  
  6210. > - a strange little thing for 'post-it' notes
  6211.  
  6212. Yeah, I wrote that. I did my own WDEF because the notes have to be tiny and
  6213. inconspicuous. There used to be some shareware post-it apps that used normal
  6214. WDEFs, and they looked pretty godawful.
  6215.  
  6216. > - the Find File windows have a funky styled background
  6217.  
  6218. So do the majority of new commercial products these days, or at least a gray
  6219. background. There's no law saying all windows have to be white.
  6220.  
  6221. > - A window that is reminiscent of the 'palette' titlebar, but with close
  6222. >   and zoom boxes.
  6223.  
  6224. That's the new official palette WDEF, right in the System file. Many people
  6225. do prefer e.g. the Infinity WDEF, but apparently the HI people had good
  6226. reasons for making this one look the way it does.
  6227.  
  6228. As for buttons, there are official Apple HI guidelines for 3D buttons. Check
  6229. out develop issue 17 (or was it 16?) which has an article complete with
  6230. pictures and sample code.
  6231.  
  6232. > What kind of message is this  
  6233. > sending to developers? It seems to me it's something like, 'Sure, go ahead,
  6234.  
  6235. > bypass the toolbox
  6236.  
  6237. Writing new WDEFs or CDEFs is not 'bypassing the toolbox', at least not in
  6238. the same sense that slamming bits onto the screen is. The Window Manager is
  6239. meant to be extensible. It's hoped that one will have a good reason for using
  6240. a custom WDEF, but at least in my case I feel that I did. (It would certainly
  6241. have been a zillion times easier for me to use a normal WDEF; writing WDEFs
  6242. from scratch is a pain.) 
  6243.  
  6244. --Jens Alfke                           jens_alfke@powertalk.apple.com
  6245.                    "A man, a plan, a yam, a can of Spam ... Bananama!"
  6246.  
  6247. +++++++++++++++++++++++++++
  6248.  
  6249. >From will@cs.su.oz.au (William Uther)
  6250. Date: 24 Aug 1994 11:28:31 +1000
  6251. Organization: Basser Dept of Computer Sciece, Uni of Sydney, Australia
  6252.  
  6253. In article <tgaul-2208942333180001@blv-pm2-ip20.halcyon.com>,
  6254. Troy Gaul <tgaul@halcyon.com> wrote:
  6255. >In article <9408222126.AA57236@geweke.ppp.msu.edu>,
  6256. >gewekean@student.msu.edu (Andrew Geweke) wrote:
  6257.  
  6258. >I don't want to go into all the details here because it is described in
  6259. >the book _Tog On Interface_.  A couple relavent quotes, from page 26:
  6260. >
  6261. >"We discovered, among other things, two pertinent facts:
  6262. >
  6263. >  -- Test subjects consistently report that keyboarding is faster than mousing.
  6264. >
  6265. >  -- The stopwatch consistently proves mousing is faster than keyboarding.
  6266. >
  6267. >  The contradiction between user-experience and reality apparently forms
  6268. >the basis for many user/developers' belief that the keyboard is faster."
  6269. >
  6270.   This raises an intesting marketing point.  From a purely pragmatic point of
  6271. view, the software producer wants the user to like the product rather than the
  6272. product actually being useful for the user.  In this case pleasing the user
  6273. would mean that you use keyboard commands because the user thinks they are
  6274. being faster.
  6275.   I'm not saying I condone the practice, but I think that if one were a
  6276. complete #@%*!!$@ one might act like this.
  6277.  
  6278. \x/ill       :-}
  6279.  
  6280. will@cs.su.oz.au
  6281. #include <stddisclaimer.h>
  6282.  
  6283.  
  6284. +++++++++++++++++++++++++++
  6285.  
  6286. >From pcastine@prz.tu-berlin.de (Peter Castine)
  6287. Date: Wed, 24 Aug 1994 11:32:36 GMT
  6288. Organization: Process Control Center
  6289.  
  6290. In article <1994Aug23.121659.18750@adobe.com>, zstern@adobe.com (Zalman
  6291. Stern) wrote:
  6292.  
  6293. > Troy Gaul writes
  6294. > > Oh, and one last parting shot: I've noticed that other complex
  6295. > > applications, including Photoshop, Illustrator, Freehand, PageMaker, Quark
  6296. > > Xpress, and many others get by fine without using toolbars at all.  Just
  6297. > > think of what life would be like if every program had a toolbar, with a
  6298. > > separate set of icons, commands, etc. (Makes me think of Windows,
  6299. > > actually...)
  6300. > We have something called the "toolbar pact" among the Photoshop engineering  
  6301. > team. Collectively, we will stop at nothing to prevent toolbars from  
  6302. > creeping into the app. On the other hand the reward for adding a cool new  
  6303. > floating palette is at least a free beer. Go figure :-)
  6304.  
  6305. Question:
  6306.  
  6307. What's the difference between a toolbar and a palette?
  6308.  
  6309. Gee, I don't *know* the answer either. I'd suggest that a well thought-out
  6310. toolbar can make sense in a UI design (actually, I have done so in other
  6311. posts). Buttons as shortcuts for frequent tasks actually makes sense. 
  6312.  
  6313. However, I also find implementation in MS products unsatisfying. I think
  6314. the problem is that for the activities in the toolbar, the icons are too
  6315. difficult to associate with the actions. Style attributes work well
  6316. enough, but Save? Undo?--as The Book says in Icons, Chapter II, Verse 28
  6317. ``Verily, I sayeth unto you, there is a time for icons and a time for
  6318. text; a time to sow, and a time to reap. And he that knoweth the
  6319. difference shall find a place at the HI beer bust.''
  6320.  
  6321. -- 
  6322. Peter Castine               | C (n.): A programming language that is sort of
  6323. pcastine@prz.tu-berlin.de   | like Pascal except more like assembly except
  6324. Process Control Center      | that it isn't very much like either one, or
  6325. Technical University Berlin | anything else.                  -- Ray Simard
  6326.  
  6327. +++++++++++++++++++++++++++
  6328.  
  6329. >From pcastine@prz.tu-berlin.de (Peter Castine)
  6330. Date: Wed, 24 Aug 1994 12:14:58 GMT
  6331. Organization: Process Control Center
  6332.  
  6333. In article <33d248$inl@falcon.bgsu.edu>, dnebing@andy.bgsu.edu (bgsuvax) wrote:
  6334.  
  6335. > gewekean@student.msu.edu (Andrew Geweke) writes:
  6336. > > Try this: Do these three 
  6337. > > things, and see which is fastest. (1) Hit a command key for a menu command. 
  6338. > > (I'm assuming you're at least a competent touch-typist). (2) Pull down the 
  6339. > > menu to that command. (3) Find the toolbar button for that command and
  6340. click 
  6341. > > it.
  6342. > > 
  6343. > > Unless the toolbar buttons are at least 40x40 pixels, I think (2) is
  6344. probably 
  6345. > > faster than (3). (1) is by far the fastest.
  6346.                      ~~~~~~~~~~~~~~~~~~~~~~~~~~
  6347.  
  6348. Do you have any studies to confirm that? There are several studies that
  6349. show (2) to be the fastest in most cases.
  6350.  
  6351. Don't believe it? Do some research (either in the lab or the library--in
  6352. the library you should look up Card's work at PARC in the early 80's).
  6353.  
  6354. >   I have one example which will prove you wrong.  On my Word toolbar,
  6355. > I have customized the toolbar.  One of the icons I have set up as
  6356. > the little paintbrush, and the command associated with it is
  6357. > 'Insert Graphic'.  There is no key command normally associated with
  6358. > this command.  It is also far down the menu so that I have to scroll
  6359. > to get to it.  In this situation, the icon is easy to identify and is
  6360. > much faster than trying to get to the menu.
  6361.  
  6362. Since you can configure your menus in Word pretty much however you want,
  6363. there are a couple of alternatives, such as defining a keyboard shortcut
  6364. for the command. However, the toolbar is not a bad solution.
  6365.  
  6366. BTW, have you tried putting the toolbar on the right side of the screen?
  6367. I've found that a much better solution. (Personal preference)
  6368.  
  6369. -- 
  6370. Peter Castine               | C (n.): A programming language that is sort of
  6371. pcastine@prz.tu-berlin.de   | like Pascal except more like assembly except
  6372. Process Control Center      | that it isn't very much like either one, or
  6373. Technical University Berlin | anything else.                  -- Ray Simard
  6374.  
  6375. +++++++++++++++++++++++++++
  6376.  
  6377. >From cwood@io.com (Charlie Wood)
  6378. Date: Wed, 24 Aug 1994 09:12:34 -0600
  6379. Organization: Illuminati Online
  6380.  
  6381. This discussion really hits home with me, since we have an internal
  6382. user-interface war raging at my company. The problem is exaggerated by the
  6383. fact that half of the development staff consists of Windows programers. No
  6384. offense.
  6385.  
  6386. I wholeheartedly agree with the low opinion of toolbars voiced here (and
  6387. totally agree that MS' UI people should be locked up). I've read Tog and
  6388. have seen His Way. I'm definitely a Mac purist at heart, even though I did
  6389. design that one five-level-deep hierarchical popup menu with 1400 items in
  6390. it. (I *swear* it was the best way! ;-)
  6391.  
  6392. But, in reading this thread, I find myself wishing for a "Next Article"
  6393. button in NewsWatcher. Yes, I can type cmd-I, but when I'm doing almost
  6394. everything else with the mouse, I wish I could access this
  6395. highly-repetitive function in the same way. Yes, of course I can select
  6396. the menu item with the mouse, but that's not nearly as elegant as a
  6397. button-click would be.
  6398.  
  6399. However, if Peter Lewis ever adds a cut, copy, or paste button, I will
  6400. become a DOS programmer just out of spite.
  6401.  
  6402. Regards,
  6403. Charlie
  6404.  
  6405. -- 
  6406. Charlie Wood     |     Wanna see me travel into the future?
  6407. cwood@io.com     |     Wanna see it again?
  6408.  
  6409. +++++++++++++++++++++++++++
  6410.  
  6411. >From fyock@mathworks.com (Lee Fyock)
  6412. Date: Wed, 24 Aug 1994 10:40:24 -0400
  6413. Organization: The MathWorks, Inc.
  6414.  
  6415. In article <1994Aug24.011125.11263@gallant.apple.com>, Jens Alfke
  6416. <jens_alfke@powertalk.apple.com> wrote:
  6417.  
  6418. > > - the Find File windows have a funky styled background
  6419. > So do the majority of new commercial products these days, or at least a gray
  6420. > background. There's no law saying all windows have to be white.
  6421.  
  6422. No, there's no law...  But page 258 of the Mac HIG says that "Apple's goal
  6423. in adding color to the interface is to enhance meaning, not just to color
  6424. things to improve aesthetics".
  6425.  
  6426. I think that the problem (if there is one) in the Find File windows is
  6427. that the background isn't a smooth gray (as kind of recommended on pg.
  6428. 265), but is a gray pattern, unlike any other window background I've ever
  6429. seen.
  6430.  
  6431. > > - A window that is reminiscent of the 'palette' titlebar, but with close
  6432. > >   and zoom boxes.
  6433. > That's the new official palette WDEF, right in the System file. Many people
  6434. > do prefer e.g. the Infinity WDEF, but apparently the HI people had good
  6435. > reasons for making this one look the way it does.
  6436.  
  6437. It scares me when people say "they must have had a good reason..."  How do
  6438. we know that it wasn't just some co-op?  :-)
  6439.  
  6440. > As for buttons, there are official Apple HI guidelines for 3D buttons. Check
  6441. > out develop issue 17 (or was it 16?) which has an article complete with
  6442. > pictures and sample code.
  6443.  
  6444. But why weren't CDEFs included?  Why aren't the CDEFs part of the system? 
  6445. Why isn't the progress bar documented and standard for the system? 
  6446. Developers are forced to write their own.  Then, when Apple changes the
  6447. appearance of windows or controls, those developers' apps look goofy.  I
  6448. remember several programs that drew their own grow icons in windows --
  6449. when System 7 came out, they were instantly dated.  That's not a great
  6450. example, since they shouldn't have drawn the grow boxes that way, but how
  6451. about apps' floating window WDEFs?  We finally have a standard, but how
  6452. long have commercial apps been using their own WDEFs for floating
  6453. windows?  Too long...
  6454.  
  6455.  
  6456. Just my 2 cents.
  6457.  
  6458.  
  6459. Have fun!
  6460. Lee
  6461.  
  6462.  
  6463. - ------------------------------------------------------------------
  6464. Lee Fyock                                    "I think I would remain
  6465. fyock@mathworks.com                                perfectly still."
  6466.  
  6467. +++++++++++++++++++++++++++
  6468.  
  6469. >From Jens Alfke <jens_alfke@powertalk.apple.com>
  6470. Date: Wed, 24 Aug 1994 22:34:38 GMT
  6471. Organization: Apple Computer
  6472.  
  6473. In article <rmah-1908940819170001@rmah.dialup.access.net> Robert Mah,
  6474. rmah@panix.com writes:
  6475. > One would expect that with Don Norman in
  6476. > charge (he is in charge of HIG isn't he?) that HIG would be less worried
  6477. > over the "look" and more about the "feel".  That they would hire fewer
  6478. > graphic designers and more people versed in psychology and sociology.
  6479.  
  6480. Apple has a mix of both, and both types of designers are involved in
  6481. products. In the 3rd party utilities I think more attention went to the
  6482. appearance since that's easier to change when the code comes from somebody
  6483. outside; although there were changes in behavior dictated during the process
  6484. (I had to deal with several of them.)
  6485.  
  6486. > The sticky note windows are even more bothersome.
  6487.  
  6488. I agree that the windows are nonstandard, but I really, really didn't think I
  6489. had a choice. Doing post-its with normal WDEFs looks really ugly. Just try it
  6490. sometime and see what you think, or look at any of the freeware post-it
  6491. programs. They suck.
  6492.  
  6493. > Looking farther into the future, does the pre-emption of the "File" menu
  6494. > with a "Document" menu in OpenDoc bother anyone?  This seems to me to be
  6495. > a gratuitous market decision in a vain attempt to differentiate" OpenDoc
  6496. > from the current crop of applications.
  6497.  
  6498. There were two reasons -- (1) to make it clear that the user is in an OpenDoc
  6499. document and not in a traditional app; this is not just a marketing thing,
  6500. since OpenDoc documents have capabilities that regular apps don't and it's
  6501. important for the user to have an idea of which they're in. And (2) to get
  6502. away from the document==file thing that may not be true in the future with
  6503. more sophisticated data storage schemes. There is nothing that says an
  6504. OpenDoc document has to live in a file.
  6505. You also mentioned the problem of menubar real estate -- most of the problems
  6506. in this regard happen on non-English systems (esp. German and French). In
  6507. those languages the name of the File menu is already more equivalent to the
  6508. English "Document" and there would not be a hit in menu size.
  6509.  
  6510. There's room for debate here, but don't jump to the conclusion that people at
  6511. Apple are idiots or totally incapable of making decisions, OK? It gets a bit
  6512. tiresome debating against that attitude.
  6513.  
  6514. --Jens Alfke                           jens_alfke@powertalk.apple.com
  6515.                    "A man, a plan, a yam, a can of Spam ... Bananama!"
  6516.  
  6517. +++++++++++++++++++++++++++
  6518.  
  6519. >From Jens Alfke <jens_alfke@powertalk.apple.com>
  6520. Date: Wed, 24 Aug 1994 23:39:54 GMT
  6521. Organization: Apple Computer
  6522.  
  6523. Andrew Southwick, andrew@csgrad.cs.vt.edu writes:
  6524. > This really (constantly) surprises me.  THIS is the part of the human
  6525. > interface that APPLE should be working on.  Why do I have to create
  6526. > all these controls by hand?  Why has Apple refused to develop these
  6527. > interface enhancements?
  6528.  
  6529. Because there's a big difference between the HI designers designing the best
  6530. way to implement a feature, and engineering actually implementing the feature
  6531. in a standard portable way (e.g. a CDEF) that will be fully tested and
  6532. released to developers.
  6533. It's hard enough just getting the major stuff that only Apple can do out the
  6534. door; usually lower-priority things like writing a date/time control either
  6535. never make it to the product stage or are canceled so their resources can be
  6536. transferred to larger projects.
  6537. On the other hand, I think that writing these kinds of controls and things is
  6538. something that'd be great for DTS to do -- they could release them with
  6539. source code both as stuff for developers to take advantage of, and as sample
  6540. code for how to write your own.
  6541.  
  6542. --Jens Alfke                           jens_alfke@powertalk.apple.com
  6543.                    "A man, a plan, a yam, a can of Spam ... Bananama!"
  6544.  
  6545. +++++++++++++++++++++++++++
  6546.  
  6547. >From absurd@apple.com (Tim Dierks)
  6548. Date: Wed, 24 Aug 1994 23:45:45 GMT
  6549. Organization: Apple Computer, Inc.
  6550.  
  6551. In article <1994Aug19.031720.1465@kira.net.netcom.com>,
  6552. netcom.com!kira!davidjohn (David John Burrowes) wrote:
  6553. ... Comments on the user interface consistency of System 7.5 ...
  6554.  
  6555. Elizabeth Moller of our Human Interface group wrote this response to David
  6556. and asked me to post it.
  6557.  
  6558. - - - - - - - - -
  6559.  
  6560. David,
  6561. Your comments got forwarded (several times) to me here in the AppleSoft
  6562. Human Interface Design Center.  I was disappointed in the quality of the
  6563. HI of the System 7.5 additions.  I think that some of the goodies are OK
  6564. using non-standard windows (sticky notes and launcher) because the design
  6565. is key to the usability.  I do wish we had the appropriate items in the
  6566. toolbox (especially the icon buttons), but that will have to wait.  There
  6567. is no HI excuse for the CD Player and the patterns in the backgrounds of
  6568. the DAs.  Our marketing folks felt they were appropriate.  The palette
  6569. (AKA utility window) titlebar is now avialable in the system.
  6570.  
  6571. We're working hard to get our toolbox updated so we have a leg to stand
  6572. on.  Unfortunately consistency for the user (in the long run) doesn't seem
  6573. to be a big selling point with our marketing dept. System 7.5 has made our
  6574. job harder for the reasons you have pointed out.  I hope there are
  6575. developers out there that still believe that standard is best.
  6576.  
  6577. Elizabeth Moller
  6578. Elizabeth.M@AppleLink.Apple.COM
  6579.  
  6580. -- 
  6581. Tim Dierks
  6582. absurd@apple.com
  6583.  
  6584. +++++++++++++++++++++++++++
  6585.  
  6586. >From kenyon@lmsc.lockheed.com (Bob Kenyon)
  6587. Date: Wed, 24 Aug 1994 22:47:12 GMT
  6588. Organization: Lockheed Missiles & Space Co.
  6589.  
  6590. In article <22AUG199415370028@csa5.lbl.gov>, sichase@csa5.lbl.gov (SCOTT I
  6591. CHASE) wrote:
  6592.  
  6593. > In article <pcastine-1908941211190001@maggie.prz.tu-berlin.de>,
  6594. pcastine@prz.tu-berlin.de (Peter Castine) writes...
  6595. > > 
  6596. > >As one example, I was looking at the new(ish) AppleCD Audio Player. The
  6597. > >only reason I even tried clicking on the little green triangle in the
  6598. > >lower left corner was because I knew that the fore-runner software had a
  6599. > >track list and I was sure that the newer software _must_ have a track list
  6600. > >somewhere. I looked in the menus, to no avail, so I started clicking
  6601. > >around and the mouse finally landed on said triangle. Voila! Success at
  6602. > >last!
  6603. > > 
  6604. > >So, in short: yes, this bothers me. Who else?
  6605. > Me!  I just discovered this last night.  I was helping a friend set up 
  6606. > her 840 AV.  Having never used an AV Mac before, I was having fun playing
  6607. > with all the neat tools.  I fooled around with the AppleCD Audio Player
  6608. > for at least 15 minutes before I accidentally, at random, hit that 
  6609. > little green triangle.  That's a button?  Jeez.
  6610.  
  6611. Hang on a sec. It just struck me that the little triangle is exactly
  6612. analogous to the triangle that appears next to the names in the "List
  6613. View" of a Finder window. When you click on those triangles, they rotate
  6614. ninety degrees and the contents "spill" out. This triangle also appears in
  6615. a number of other programs, one of which is InterSLIP. 
  6616.  
  6617. It's a new paradigm, but it's not unreasonable.
  6618.  
  6619. Bob
  6620.  
  6621. -- 
  6622. Bob Kenyon (bkenyon@lmsc.lockheed.com)            | "It's called Windows
  6623. Spacecraft Engineering & Technology               |  because it's a real
  6624. Lockheed Missiles & Space Co., Sunnyvale, CA USA  |  pane." - Dave Barry
  6625.  
  6626. +++++++++++++++++++++++++++
  6627.  
  6628. >From egmiller@cpcug.org (Eric G. Miller)
  6629. Date: Wed, 24 Aug 1994 22:29:48 -0500
  6630. Organization: Express Access Online Communications, USA
  6631.  
  6632. In article <cwood-2408940912340001@slip-2.io.com>, cwood@io.com (Charlie
  6633. Wood) wrote:
  6634. > But, in reading this thread, I find myself wishing for a "Next Article"
  6635. > button in NewsWatcher. Yes, I can type cmd-I, but when I'm doing almost
  6636. > everything else with the mouse, I wish I could access this
  6637. > highly-repetitive function in the same way. Yes, of course I can select
  6638. > the menu item with the mouse, but that's not nearly as elegant as a
  6639. > button-click would be.
  6640.  
  6641. Yes, the ability to repeat the same action over and over by just clicking
  6642. the mouse button (with one hand) is really great for those times when you
  6643. are trying to enjoy a really slimy/greasy snack (with the other hand).
  6644. Toolbars may stink but they rank well above keyboard condoms in my book.
  6645. The human-computer interface is neither as time-tested                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                atcher. Yes, I can type cmd-I, but when I'm doing almost
  6646. > everything else with the mouse, I wish I could access this
  6647. > highly-repetitive function in the same way. Yes, of course I can select
  6648. > the menu item with the mouse, but that's not nearly as elegant as a
  6649. > button-click would be.
  6650.  
  6651. What are you doing with the mouse in NewsWatcher?  The spacebar, or the
  6652. keypad 0 work pretty well for "next article".
  6653.  
  6654. -- Bruce
  6655.  
  6656. +++++++++++++++++++++++++++
  6657.  
  6658. >From mab22@po.cwru.edu (Mike Balfour)
  6659. Date: 25 Aug 1994 15:48:34 GMT
  6660. Organization: Overload Engineering
  6661.  
  6662. In article <33i6gh$sfa@romulus.ucs.uoknor.edu>, Willie Abrams
  6663. <willie-abrams@uokhsc.edu> wrote:
  6664.  
  6665. > Why isn't Elizabeth (or anyone in HIG) being heard? Is marketing truly
  6666. > to blame for all of this? If so, I am much more worried about the HI
  6667. > stuff now than when I was at WWDC. At least there, it seemed, that
  6668. > HI was a critical point in the entire Apple world view.
  6669. > What was the quote, "The user is the center of everything we do." -
  6670. > I hope for all of our sakes, as Apple developers, employees and users,
  6671. > that the quality of the Human-Machine interaction remains paramount
  6672. > in our minds. And, it would seem, the best group to steer and maintain
  6673. > that quality at Apple is the HIG, not marketing.
  6674.  
  6675. Well, here's a little something to consider before jumping on Apple.  It
  6676. could be that they're ditching some of these standards because the user
  6677. wants it that way (of course, what's *best* for the user doesn't
  6678. matter:).  When someone's out there trying to decide which computer to
  6679. buy, and they see a Mac with a CD-ROM drive with this cool window on the
  6680. screen that controls it - a window that will make their computer look cool
  6681. to their friends - it appeals to them.  It's what they want, so they buy
  6682. it.
  6683.  
  6684. While HIG is best suited for determining how to make the machine easiest
  6685. to use, marketing really is the best group for determining what the user
  6686. wants, unfortunately.  In my opinion, this *does* seem like a rather blind
  6687. way of looking at things, 'cause the easiest-to-use machine is ultimately
  6688. what the user will want, if it's done correctly.  Candy features are nice,
  6689. and they'll sell things, and they appeal to people, but they'll only give
  6690. you empty calories and rot your teeth :).
  6691.  
  6692. (BTW Jens, don't take offense at my calling the post-it notes that you
  6693. designed "candy".  I'm a chocoholic.:)
  6694.  
  6695. To sum up:  Don't jump on Apple's case too quickly.  As a company, they're
  6696. not here to tell us what's best for us; they're here to give us what we
  6697. want, and what we ask for...
  6698.  
  6699. Should I smiley that last sentence?
  6700.  
  6701. MB
  6702. -- 
  6703. - --------------------------------+--------------------------------
  6704. Mike Balfour, Partner             | BS/MS Candidate - ECMP
  6705. Overload Engineering              | Case Western Reserve University
  6706. "New Ideas for a Brighter Future" | Cleveland, OH
  6707.  
  6708. +++++++++++++++++++++++++++
  6709.  
  6710. >From Willie Abrams <willie-abrams@uokhsc.edu>
  6711. Date: 26 Aug 1994 13:57:42 GMT
  6712. Organization: OU Health Sciences Center
  6713.  
  6714. In article <mab22-2508941148490001@law47118.law.cwru.edu> Mike Balfour,
  6715. mab22@po.cwru.edu writes:
  6716. >While HIG is best suited for determining how to make the machine easiest
  6717. >to use, marketing really is the best group for determining what the user
  6718. >wants, unfortunately.  In my opinion, this *does* seem like a rather
  6719. blind
  6720.  
  6721. I agree. Case in point, ideally the interaction should go like this:
  6722.  
  6723. Marketing: The user needs to be able to do this.
  6724.  
  6725. Engineering: We can program anything... :-)
  6726.  
  6727. HIG: This is what the user experience should be.
  6728.  
  6729. Not marketing deciding what interface is appropriate, and
  6730. HIG not being utilized for their expertize.
  6731.  
  6732. I am not jumping on Apple, per se, but I use and program Macs
  6733. by choice. The entire user experience and consistency of the
  6734. Mac is the reason I use them. The minute I start getting visually
  6735. assualted by my Macintosh is the minute I start panicking.
  6736.  
  6737. The moment I spend trying to figure out why I can't find the
  6738. program list in the CD remote, or why the find file box has got
  6739. a weirdo color scheme unlike the rest of Mac, is a moment lost
  6740. for no good reason. Do it consistently or don't do it at all.
  6741.  
  6742. I won't standby and watch my Mac turn into an enitre mish-mash
  6743. of metaphors, visual clues, and interface elements. I will turn
  6744. it off first.
  6745.  
  6746. Willie Abrams                                  willie-abrams@uokhsc.edu
  6747.  
  6748.        Less is more. God is in the details. - Mies van der Rohe
  6749.  
  6750. +++++++++++++++++++++++++++
  6751.  
  6752. >From Hank_Gillette@smtp.esl.com (Hank Gillette)
  6753. Date: 26 Aug 1994 23:05:05 GMT
  6754. Organization: esl.com
  6755.  
  6756. In article <33d248$inl@falcon.bgsu.edu>, dnebing@andy.bgsu.edu (bgsuvax) wrote:
  6757.  
  6758. >   I have one example which will prove you wrong.  On my Word toolbar,
  6759. > I have customized the toolbar.  One of the icons I have set up as
  6760. > the little paintbrush, and the command associated with it is
  6761. > 'Insert Graphic'.  There is no key command normally associated with
  6762. > this command.  It is also far down the menu so that I have to scroll
  6763. > to get to it.  In this situation, the icon is easy to identify and is
  6764. > much faster than trying to get to the menu.
  6765.  
  6766. But there's nothing stopping you from assigning a key command to 'Insert
  6767. Graphic', since Word allows you to assign key commands to any command.
  6768.  
  6769. Hank Gillette
  6770.  
  6771. -- 
  6772.  
  6773. Hank_Gillette@smtp.esl.com
  6774.  
  6775. +++++++++++++++++++++++++++
  6776.  
  6777. >From rmah@panix.com (Robert Mah)
  6778. Date: Sat, 27 Aug 1994 00:08:29 -0500
  6779. Organization: One Step Beyond
  6780.  
  6781. Willie Abrams <willie-abrams@uokhsc.edu> wrote:
  6782.  
  6783. ) The moment I spend trying to figure out why I can't find the program
  6784. ) list in the CD remote, or why the find file box has got a weirdo color
  6785. ) scheme unlike the rest of Mac, is a moment lost for no good reason.
  6786. ) Do it consistently or don't do it at all.
  6787. ) I won't standby and watch my Mac turn into an enitre mish-mash of 
  6788. ) metaphors, visual clues, and interface elements. I will turn it off
  6789. ) first.
  6790.  
  6791. Amen.  Only on the Mac could you have the audience of a demo tell the 
  6792. demonstrator how to access functions that they've never seen.  I've seen
  6793. it happen.  The reason it can happen is the interface consistency between
  6794. applications.  This is more than just conforming to guidelines, it also
  6795. includes being aware that _other_ people may have had the same interface
  6796. problem and making your solution similar to theirs.
  6797.  
  6798. I'm afraid that Apple is losing it's way.  I wonder how much the top execs
  6799. actually use their Macs for more than writing memos.
  6800.  
  6801. Cheers,
  6802. Rob
  6803. _____________________________________________________________________
  6804. Robert S. Mah           Software Development          +1.212.947.6507
  6805. One Step Beyond        and Network Consulting          rmah@panix.com
  6806.  
  6807. +++++++++++++++++++++++++++
  6808.  
  6809. >From dnebing@andy.bgsu.edu (bgsuvax)
  6810. Date: 27 Aug 1994 18:00:19 GMT
  6811. Organization: Bowling Green State University
  6812.  
  6813. Hank_Gillette@smtp.esl.com (Hank Gillette) writes:
  6814. > In article <33d248$inl@falcon.bgsu.edu>, dnebing@andy.bgsu.edu (bgsuvax) wrote:
  6815. >>   I have one example which will prove you wrong.  On my Word toolbar,
  6816. >> I have customized the toolbar.  One of the icons I have set up as
  6817. >> the little paintbrush, and the command associated with it is
  6818. >> 'Insert Graphic'.  There is no key command normally associated with
  6819. >> this command.  It is also far down the menu so that I have to scroll
  6820. >> to get to it.  In this situation, the icon is easy to identify and is
  6821. >> much faster than trying to get to the menu.
  6822. > But there's nothing stopping you from assigning a key command to 'Insert
  6823. > Graphic', since Word allows you to assign key commands to any command.
  6824.  
  6825.   Yes, but conceivably one could have so many keyboard commands in word
  6826. that it is easy to forget what one might be.  However, a familiar icon
  6827. in the toolbar is hard to forget.
  6828.  
  6829. Dave
  6830.  
  6831. ============================================================
  6832. Dave Nebinger                    dnebing@bgsuvax.bgsu.edu
  6833. Network Manager, Biology Dept.   dnebing@opie.bgsu.edu
  6834. Bowling Green State University   dnebing@bgsuopie (bitnet)
  6835. Bowling Green, OH 43403          #include <std_disclaimer.h>
  6836.  
  6837.              *THE* alt.sources.mac supporter!
  6838. >From eric.larson@f620.n2605.z1.fidonet.org (eric larson)
  6839. Subject: Where have the standards gone? [a high level question]
  6840. Date: 20 Aug 94 09:31:50 -
  6841. Organization: FidoNet: Shockwave Rider, USR V.Everything +1(908)294-0659 
  6842.  
  6843.  > That said, let me add that it *is* important for UIs to develop; I'm not
  6844.  > going to advocate cast-in-platinum Human Interface Guidelines. The
  6845.  > _Macintosh Humand Interface Guidelines_ discuss the subject of ``Going
  6846.  > Beyond the Guidelines'' quite specifically.
  6847.  
  6848.  > So, in short: yes, this bothers me. Who else?
  6849.  
  6850. Me too. The consistency of the Apple user interface has long been one of it's
  6851. strengths. Having so many disparate design elements onscreen is quite jarring
  6852. to someone really used to the standard ways of doing things.
  6853.  
  6854. It's one thing to introduce new elements to support new technologies (OpenDoc's
  6855. interface elements might well need to EXTEND the current paradigm
  6856. considerably), or to replace elements when a better way becomes obvious. But it
  6857. should be done in a CONSISTENT fashion. The Zoom box should be the same on
  6858. EVERYTHING. The StickyNotes stuff is an abomination.
  6859.  
  6860. +++++++++++++++++++++++++++
  6861.  
  6862. >From heilmayr@uclink.berkeley.edu (Klaus)
  6863. Date: 29 Aug 1994 02:13:11 GMT
  6864. Organization: Parentheses and Ellipses
  6865.  
  6866. In article <1994Aug24.011125.11263@gallant.apple.com>
  6867. Jens Alfke <jens_alfke@powertalk.apple.com> writes:
  6868.  
  6869. > The fundamental issue is that the HI has to move forward;
  6870. > that the old mostly black and white interface is getting old.
  6871.  
  6872. What does it mean for the HI to "move forward"?  Yes, the interface is getting
  6873. old, but that doesn't mean it's going bad.  As someone once remarked, the
  6874. usual windows interface looks like an explosion in a cartoon factory.  A wild
  6875. jumble of colors and patterns, for no apparent reason other than to look
  6876. whizzy.  It's the computer equivalent of those stereo components with lots of
  6877. pointless buttons and flashing lights whose only purpose is to make the box
  6878. look high-tech.  In fact, it just looks tacky.  I think one of the reasons
  6879. that graphic design professionals like to use Macs is that the Mac has an
  6880. elegant interface.  I'd hate to see Apple give up that elegance in the name of
  6881. "moving forward."
  6882.  
  6883. >> - the Find File windows have a funky styled background
  6884. > So do the majority of new commercial products these days, or at least a
  6885. > gray background. There's no law saying all windows have to be white.
  6886.  
  6887. No, there's no law, but it violates one of the principles of user interface
  6888. design: consistency.  One should not change the interface unless there is a
  6889. good reason for the change
  6890.  
  6891.  -Klaus (heilmayr@math.berkeley.edu)
  6892.  
  6893. +++++++++++++++++++++++++++
  6894.  
  6895. >From heilmayr@uclink.berkeley.edu (Klaus)
  6896. Date: 29 Aug 1994 02:23:43 GMT
  6897. Organization: Parentheses and Ellipses
  6898.  
  6899. In article <mab22-2508941148490001@law47118.law.cwru.edu>
  6900. mab22@po.cwru.edu (Mike Balfour) writes:
  6901.  
  6902. > Well, here's a little something to consider before jumping on Apple.  It
  6903. > could be that they're ditching some of these standards because the user
  6904. > wants it that way
  6905.  
  6906. What I suspect is that it's not the current Mac users who want it that way,
  6907. but the Windows users whom Apple is trying to win over.  Unfortunately, making
  6908. a Mac look like a Windows box isn't likely to win over many Windows users, but
  6909. it'll probably alienate a lot of Mac users.  Most Windows users have chosen
  6910. their platform because it's the most common one, or because there are more
  6911. applications (especially games) available for it.  Most Mac users have chosen
  6912. their platform because of its elegant and consistent interface.  Making the
  6913. Mac more like a Windows box won't really give  the Windows users any reasons
  6914. to switch, but it may well make some Mac users decide that there's no reason
  6915. to stick with the Mac.
  6916.  
  6917.  -Klaus (heilmayr@math.berkeley.edu)
  6918.  
  6919. ---------------------------
  6920.  
  6921. End of C.S.M.P. Digest
  6922. **********************
  6923.  
  6924.  
  6925. ˇ